Svelte

Integrating Storybook with SvelteKit, TypeScript, and SCSS

Published Mar 16, 2023

Updated Oct 12, 2023

3 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Introduction

Storybook is a great tool for testing, and visualizing your components in different states.

Storybook allows teams to collaborate to develop durable UIs in isolation. It allows users to implement reusable components without fussing with data, APIs, or business logic.

In this article, we will discuss how to integrate Storybook in a SvelteKit project with TypeScript, and SCSS support.

Zero-config set up

To get started, run the following in the root of an existing Svelte project:

    npx sb@next init

This detects the project type, installs @storybook/svelte, and adds some sample files to demonstrate the basics of Storybook. Running npm run storybook gives you the following zero-config set up on http://localhost:6006

Project Structure

Our project structure is already set up by SvelteKit, and Storybook initialization has created a .storybook folder. Still, we need to make some changes to the Storybook file extension, since our project is in TypeScript. This is a snippet of the folders in our project:

    ├── .storybook
        ├── main.cjs
        ├── preview.js
        └── preview-head.html
    ├── vite.config.ts
    └── src

Add SCSS support

To add SCSS support, we need the @storybook/preset-scss addon.

Install sass, @storybook/preset-scss, and other relevant style loaders.

npm i -D sass @storybook/preset-scss css-loader sass-loader style-loader

Navigate to storybook/main.cjs

Add @storybook/preset-scss to the addons' array.

	addons: [
		'@storybook/addon-links',
		'@storybook/addon-essentials',
		'@storybook/addon-interactions',
		'@storybook/preset-scss' // add here
	],

Add $lib alias support

Navigate to .storybook/main.cjs.

Import mergeConfig from Vite. This deeply merges two Vite configs.

Import path. The path module provides utilities for working with file, and directory paths.

Finally, we need to resolve the $lib to point to ../src/lib for Storybook.

async viteFinal(config) {
    return mergeConfig(config, {
        resolve: {
            alias: { $lib: path.resolve(__dirname, '../src/lib') }
        }
    });
}

Your .storybook/main.cjs should contain the following:

// .storybook/main.cjs

const { mergeConfig } = require("vite");
const path = require("path");

module.exports = {
  stories: ["../src/**/*.mdx", "../src/**/*.stories.@(js|jsx|ts|tsx)"],
  addons: [
    "@storybook/addon-links",
    "@storybook/addon-essentials",
    "@storybook/addon-interactions",
    "@storybook/preset-scss",
  ],
  framework: {
    name: "@storybook/sveltekit",
    options: {},
  },
  docs: {
    autodocs: "tag",
  },
  async viteFinal(config) {
    return mergeConfig(config, {
      resolve: {
        alias: { $lib: path.resolve(__dirname, "../src/lib") },
      },
    });
  },
};

Creating Stories

We will start by creating a Greeting.svelte file that receives a message from our server.

    <script lang="ts">
        export let message: string;
    </script>

    <div class="fetch-container">
        <header>
            <h1>SvelteKit Fetch Data from API</h1>
        </header>
        <div>
            Message: {message}
        </div>
    </div>

    <style lang="scss">
        .fetch-container {
            text-align: center;

            header {
              margin: 1.25rem auto;
              width: 40%;

              h1 {
                padding: 0.9375rem 0;
                font-size: 2rem;
                text-align: center;
                border-bottom: 5px solid #1d4ed8;
              }
            }

            div {
              font-size: 1.2rem;
              display: flex;
              justify-content: center;
            }
        }
    </style>

Then a Greeting.stories.ts with a message argument:

    import Greeting from './Greeting.svelte';

    export default {
        component: Greeting,
        title: 'Example/Greeting',
        excludeStories: /.*Data$/,
        argTypes: {
            message: 'from Storybook',
        },
    };

    const Template = ({ ...args }) => ({
        Component: Greeting,
        props: args,
    });

    export const Default = Template.bind({});
        Default.args = {
        message: 'from This Dot’,
    };

Simply run npm run storybook to see if your story is running:

You can edit the argument to test different messages.

Conclusion

In this article, we learned how to set up Storybook in a SvelteKit project, and created our first story.

If you are looking to bootstrap your next project, check out our starter kit that uses SvelteKit and SCSS.

Thanks for reading!

If you have any questions or run into any trouble, feel free to reach out on Twitter.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Ian Sam Mungai
@iansamz @iansamz

A Deep Dive into SvelteKit's Rendering Techniques

A Deep Dive into SvelteKit's Rendering Techniques Introduction SvelteKit is a meta-framework for Svelte that allows you to develop pages based on their content. At its core, SvelteKit introduces three fundamental strategies out of the box, each designed to streamline the development process and adapt to the specific needs of your project. These strategies enable you to easily create dynamic, responsive, and highly interactive web applications. These strategies, or as SvelteKit calls them, page options, are: * Prerender: Ideal for static content that doesn't change, making your pages lightning-fast to load. * SSR (Server-Side Rendering): Ideal for rendering full pages with dynamic content from a server. * CSR (Client-Side Rendering): Best for highly dynamic and interactive applications where content updates frequently based on user actions. These page options can be applied to specific pages (when exported from **+page.js or +page.server.js) or to a group of pages (when exported from +layout.js or +layout.server.js). They can also be set across the entire application. You accomplish this by exporting it from the root layout. It's worth noting that child layouts and pages can supersede settings from parent layouts. This means you could activate prerendering for the whole app and then turn it off for certain pages that require dynamic server rendering (SSR). In this blog post, we'll explore these page options and share some insights on how you might use them in everyday web projects. Prerendering Prerendering is akin to taking a snapshot of your web pages when you build your application; you might have heard of this as static rendering. This snapshot is then served to all users, ensuring lightning-fast load times since the server simply delivers the pre-built files without additional processing rather than dynamically generating the files for each request. This method is perfect for content that remains unchanged across visits, such as blog posts, documentation, or landing pages. In other words, pages with no dynamic content. There will be situations where you would like to avoid using this option, though. The rule of thumb is that if two different users will see different content, then this is a no-go. Other reasons are inconvenience for your needs. For example, your build times could drag if you end up prerendering tons of pages. Is that convenient to you? Well, that’s for you to decide! The prerender option is turned off by default, so we need to enable it if we want to start using it. Export the following in the +page.server.js or just +page.js: ` Likewise, if you have a group of pages, you could do the same inside a +layout.js or +layout.server.js . If your app is suitable to be all SSG (Static Side Generation), you could use adapter-static, which will output files suitable for use with any static web server. In cases where you happen to opt-in for this, you could turn off pages that need dynamic rendering: ` Another cool feature about prerendering is that pages that fetch data from server routes can automatically inherit default values during the prerendering process. This feature simplifies data management and enhances the development workflow, especially when dealing with dynamic content that needs to be prerendered with specific data sets. Let's say you have a blog where each post fetches its content from a server route when the page loads. Normally, this would require the user's browser to make a request to the server at runtime. However, with prerendering, you can have this data fetched and embedded into the page at build time. ` In this example, when the blog/[slug].sveltepage is prerendered, it makes a fetch call to /api/posts/[slug], which returns the post data. This data is then used to prerender the blog post page with the content already in place, allowing the page to load instantly for the user, with the blog post content visible even before any JavaScript is executed on the client side. There’s a third and useful option when prerendering: ` Using this option is like telling SvelteKit to make a smart guess about whether to prerender your page in advance. You're saying, "Hey SvelteKit, you decide if this page should be prerendered based on what you find about the page" SvelteKit analyzes your page and if it determines the page can be prerendered without complications, it will automatically generate a prerendered version. This process involves SvelteKit either crawling a link inside an already prerendered page, prerendering entry points or targeting pages that are specifically marked for prerendering set in entries. An example is a blog section where you post articles regularly. The blog section has a main page that lists all your blog posts and individual pages for each blog post. The structure for this might be something like: In this setup, the /blog main entry page will be prerendered automatically. However, individual blog posts at paths like /blog/[slug] will not be prerendered unless linked directly from another prerendered page. For instance, if there’s a link to /blog/some-cool-slug, like: <a href="/blog/some-cool-slug">, SvelteKit will be able to crawl that link and prerender that specific page as well. Now let’s say that you would like to prerender your latest blog post, but there's no link for SvelteKit to crawl to this page. In these cases, you can explicitly add these pages to the prerender entries list. By doing so, SvelteKit will prerender every specified entry, ensuring that the content is immediately accessible to users. You can configure the prerender entries directly in your svelte.config.js file or by exporting an entries function from a +page.js, a +page.server.js or a +server.js belonging to a dynamic route. Here’s how you can do it: ` SSR SSR is similar to prerendering. It ensures that pages are first rendered on the server. This process generates the complete HTML content, which is then sent to the client for hydration). This approach enhances the initial page load performance and SEO, providing a better user experience. Unlike prerendering, where pages are generated at build time, SSR pages are created at runtime. This key difference allows for the generation of dynamic content, making SSR particularly suited for applications that require personalized content for each user or real-time updates, such as user dashboards, e-commerce sites, and social media platforms. Similar to prerendering, SSR comes with its own set of limitations, and there are scenarios where it might not be the best choice for your project: * SSR can be expensive. It can significantly load your server, especially for high-traffic sites, as each page request involves rendering content on the server. If server resources are constrained, this could lead to performance bottlenecks. * Highly Interactive Applications: Applications that rely heavily on user interactions and real-time updates (like games or interactive tools like an admin panel) might not benefit much from SSR. CSR can provide a smoother user experience in these cases, as it minimizes server requests after the initial load. * SEO Is Not YOUR Priority: If search engine optimization isn't a key concern for your project (for example, an internal dashboard or an app behind a login), the SEO benefits of SSR might not justify the additional complexity and server demands. export const ssr = true is the option enabled by default. Thus, we can use its benefits from the start. To execute code exclusively on the server, such as fetching data from a database or an external API, SvelteKit offers a convention using +page.server.js files. This setup is ideal for server-side operations, ensuring sensitive logic and credentials are not exposed to the client. ` Note: When you employ +page.js in SvelteKit, the contained code is executed on both the server and client sides by default. However, if you intend for the code to run exclusively on the client side, you can disable SSR by setting export const ssr = false within your +page.js file. Doing so ensures that the code is only executed in the browser, adhering to client-side rendering principles and turning your app into a SPA. This is useful for cases where you don’t need the load on the server, or you don’t benefit from any of the benefits of SSR. CSR CSR plays a crucial role in making web pages interactive by hydrating them and incorporating JavaScript. JavaScript is crucial for adding interactivity to web pages—everything from animations and video players to form validations and dynamic content updates relies on JavaScript. However, there are instances where JavaScript is unnecessary. Consider a prerendered 'About' page; enabling CSR on this page could be excessive, especially if it lacks interactive elements. In such scenarios, you can streamline your page by disabling CSR that comes enabled by default, which can be done by simply doing this: ` Using this trick smartly can make your web pages load fast because downloading JavaScript is sometimes heavy. The key lies in strategically combining this approach with other rendering techniques to optimize performance and user experience. One factor to consider, though, is that turning off CSR also means you'll lose client-side routing. This requires you to depend on traditional browser navigation instead. Conclusion By thoughtfully applying these strategies, you can craft a SvelteKit application that performs exceptionally and delivers a fantastic user experience tailored to your audience's needs. Wrapping up our journey through SSR with SvelteKit. We discovered how choosing the right way to render pages (like prerendering, SSR, or CSR) is super important and can make a big difference in how well a website works. SvelteKit is awesome because it lets you pick the best method for your website. So, remember, playing with SvelteKit and these rendering methods can make your websites stand out. Use it to build websites that not only work great but are also fun and easy for people to use. Dive in, try things out, and see how your web projects can shine!...

May 1, 2024

7 mins

SvelteSEOJavaScriptWeb Performance

Harnessing the Power of Threlte - Building Reactive Three.js Scenes in Svelte

Introduction Web development has evolved to include immersive 3D experiences through libraries like Three.js. This powerful JavaScript library enables the creation of captivating 3D scenes within browsers. Three.js: The 3D Powerhouse Three.js democratizes 3D rendering, allowing developers of all skill levels to craft interactive 3D worlds. Svelte Ecosystem: Svelte Cubed and Svelthree The Svelte ecosystem presents solutions like Svelte Cubed and Svelthree, which bridges Svelte with Three.js, offering streamlined reactivity for 3D web experiences. Introducing Threlte v6: Uniting SvelteKit 1.0, Svelte 4, and TypeScript Threlte v6 is a rendering and component library for Svelte that seamlessly integrates Three.js. By harnessing TypeScript's types, it provides a robust and delightful coding experience. In this tutorial, we'll showcase Threlte's capabilities by building an engaging website header: an auto-rotating sphere that changes color on mouse down. Using Threlte v6, SvelteKit 1.0, and Three.js, we're set to create a visually stunning experience. Let's dive in! Setting up Threlte Before building our scene, we need to set up Threlte. We can scaffold a new project using the CLI or manually install Threlte in an existing project. Option 1: Scaffold a New Threlte Project Create a new SvelteKit project and install Threlte with: ` Option 2: Manual Installation For an existing project, select the necessary Threlte packages and install: ` Configuration adjustments for SvelteKit can be made in the "vite.config.js" file: ` With Threlte configured, we're ready to build our interactive sphere. In the next chapter, we'll lay the groundwork for our exciting 3D web experience! Exploring the Boilerplate of Threlte Upon scaffolding a new project using npm create threlte, a few essential boilerplate files are generated. In this chapter, we'll examine the code snippets from three of these files: lib/components/scene.svelte, routes/+page.svelte, and lib/components/app.svelte. 1. lib/components/scene.svelte: This file lays the foundation for our 3D scene. Here's a brief breakdown of its main elements: - Perspective Camera: Sets up the camera view with a specific field of view and position, and integrates OrbitControls for auto-rotation and zoom management. - Directional and Ambient Lights: Defines the lighting conditions to illuminate the scene. - Grid: A grid structure to represent the ground. - ContactShadows: Adds shadow effects to enhance realism. - Float: Wraps around 3D mesh objects and defines floating properties, including intensity and range. Various geometrical shapes like BoxGeometry, TorusKnotGeometry, and IcosahedronGeometry are included here. 2. routes/+page.svelte: This file handles the ui of the index page and imports all necessary components we need to bring our vibrant design to life. 3. lib/components/app.svelte: This file is where you would typically define the main application layout, including styling and embedding other components. Heading to the Fun Stuff With the boilerplate components explained, we're now ready to dive into the exciting part of building our interactive 3D web experience. In the next section, we'll begin crafting our auto-rotating sphere, and explore how Threlte's robust features will help us bring it to life. Creating a Rotating Sphere Scene In this chapter, we'll walk you through creating an interactive 3D sphere scene using Threlte. We'll cover setting up the scene, the sphere, the camera and lights, and finally the interactivity that includes a scaling effect and color changes. 1. Setting Up the Scene First, we need to import the required components and utilities from Threlte. ` 2. Setting Up the Sphere We'll create the 3D sphere using Threlte's and components. ` 1. : This is a component from Threlte that represents a 3D object, which in this case is a sphere. It's the container that holds the geometry and material of the sphere. 2. : This is the geometry of the sphere. It defines the shape and characteristics of the sphere. The args attribute specifies the parameters for the sphere's creation: - The first argument (1) is the radius of the sphere. - The second argument (32) represents the number of width segments. - The third argument (32) represents the number of height segments. 3. : This is the material applied to the sphere. It determines how the surface of the sphere interacts with light. The color attribute specifies the color of the material. In this case, the color is dynamic and defined by the sphereColor variable, which updates based on user interaction. The roughness attribute controls the surface roughness of the sphere, affecting how it reflects light. 3. Setting Up the Camera and Lights Next, we'll position the camera and add lights to create a visually appealing scene. ` 1. : This component represents the camera in the scene. It provides the viewpoint through which the user sees the 3D objects. The position attribute defines the camera's position in 3D space. In this case, the camera is positioned at (-10, 20, 10). The fov attribute specifies the field of view, which affects how wide the camera's view is. - makeDefault: This attribute makes this camera the default camera for rendering the scene. 2. : This component provides controls for easy navigation and interaction with the scene. It allows the user to pan, zoom, and orbit around the objects in the scene. The attributes within the component configure its behavior: - enableZoom: Disables zooming using the mouse scroll wheel. - enablePan: Disables panning the scene. - enableDamping: Enables a damping effect that smoothens the camera's movement. - autoRotate: Enables automatic rotation of the camera around the scene. - autoRotateSpeed: Defines the speed of the auto-rotation. 3. : This component represents a directional light source in the scene. It simulates light coming from a specific direction. The attributes within the component configure the light's behavior: - intensity: Specifies the intensity of the light. - position.x and position.y: Define the position of the light source in the scene. 4. : This component represents an ambient light source in the scene. It provides even lighting across all objects in the scene. The intensity attribute controls the strength of the ambient light. 4. Interactivity: Scaling and Color Changes Now we'll add interactivity to the sphere, allowing it to scale and change color in response to user input. First, we'll import the required utilities for animation and set up a spring object to manage the scale. ` We'll update the sphere definition to include scaling: ` Lastly, we'll add code to update the color of the sphere based on the mouse's position within the window. ` We have successfully created a rotating sphere scene with scaling and color-changing interactivity. By leveraging Threlte's capabilities, we have built a visually engaging 3D experience that responds to user input, providing a dynamic and immersive interface. Adding Navigation and Scroll Prompt in app.svelte In this chapter, we'll add a navigation bar and a scroll prompt to our scene. The navigation bar provides links for user navigation, while the scroll prompt encourages the user to interact with the content. Here's a step-by-step breakdown of the code: 1. Importing the Canvas and Scene The Canvas component from Threlte serves as the container for our 3D scene. We import our custom Scene component to render within the canvas. ` 2. Embedding the 3D Scene The Canvas component wraps the Scene component to render the 3D content. It is positioned absolutely to cover the full viewport, and the z-index property ensures that it's layered behind the navigation elements. ` 3. Adding the Navigation Bar We use a element to create a horizontal navigation bar at the top of the page. It contains a home link and two navigation list items. The styling properties ensure that the navigation bar is visually appealing and positioned correctly. ` 4. Adding the Scroll Prompt We include a "Give a scroll" prompt with an element to encourage user interaction. It's positioned near the bottom of the viewport and styled for readability against the background. ` 5. Styling the Components Finally, the provided CSS styles control the positioning and appearance of the canvas, navigation bar, and scroll prompt. The CSS classes apply appropriate color, font, and layout properties to create a cohesive and attractive design. ` Head to the github repo to view the full code. Check out the result: https://threlte6-spinning-ball.vercel.app/ Conclusion We've successfully added navigation and a scroll prompt to our Threlte project in the app.svelte file. By layering 2D HTML content with a 3D scene, we've created an interactive user interface that combines traditional web design elements with immersive 3D visuals....

Aug 14, 2023

6 mins

Svelte

Introducing the All New SvelteKit and SCSS Kit for starter.dev

Introduction At This Dot Labs, we love Svelte. We've even created a starter.dev kit for SvelteKit that you can use to scaffold your next frontend project using SCSS, TypeScript, Vitest and Storybook. What is starter.dev? Starter.dev helps developers get started building web apps with a variety of frameworks, showcasing how various libraries can fit together to solve similar problems. To do that, This Dot Labs has built a series of showcase apps that recreate the experience of using GitHub. What is SvelteKit? How is it unique? SvelteKit is a full-stack framework that gives you the best of both worlds: the page is server-side rendered on your first visit, but when you navigate to other pages, they are client-side rendered. SvelteKit gives you levers for your pages to use SSR (server-side rendering), CSR (client-side rendering), SSG (static site generation), SPA (single page application) & MPA (multi page application). The core of SvelteKit provides a highly configurable rendering engine. Why SvelteKit and not Svelte? SvelteKit isn’t built on top of Svelte, but it’s a backend web framework where Svelte is used as the view layer. In theory, you could rip it out and replace it with another component framework that supports server-side rendering, and the same is true for other web frameworks. This allows us to deploy everything as a Node server, or even use Vercel and serverless functions. Other reasons to use SvelteKit include: 1. Pages (file based routing) 2. Endpoints (API routes) 3. Nested layouts (way more powerful than just nesting files because the segment of the URL maps to your component hierarchy) 4. Hot module replacement (instant updates in the browser when you make a change preserving application state) 5. Preprocessing (TypeScript, SCSS, and Pug among others) 6. Building component libraries (creating and publishing npm packages) 7. Deployment options (adapters for any platform) Building a SvelteKit showcase presented several challenges given its uniqueness and different approach to building web apps. This blog post details what we chose to include in our SvelteKit GitHub clone, and how we integrated them. Project Structures and Naming Conventions SvelteKit has unique conventions in its project structure and naming conventions. Project Files src This is the meat of the project: - lib contains your library code, which can be imported via the $lib alias, or packaged up for distribution using svelte-package. It can be imported by using the $lib/* alias. - server contains your server-only library code. SvelteKit will prevent you from importing these in client code. - components contain single responsibility components that are imported in our routes. They typically contain three files: .spec.ts for unit tests, .svelte and .stories.ts for storybook stories. Barrel files were not necessary here. - images contains images that can be imported, and used in the project. - stores contains state that needs to be accessed by multiple unrelated components, or by a regular JS module. - styles contains styles that can be imported in our Svelte applications. - params contains any param matchers your app needs - routes contains the routes of your application - app.html is your page template — an HTML document containing the following placeholders: - %sveltekit.head% — link and script elements needed by the app, plus any head content - %sveltekit.body% — the markup for a rendered page. This should live inside a or other element, rather than directly inside the body element, to prevent bugs caused by browser extensions injecting elements that are then destroyed by the hydration process. SvelteKit will warn you in development if this is not the case - %sveltekit.assets% — either paths.assets, if specified, or a relative path to paths.base - %sveltekit.nonce% — a CSP nonce for manually included links and scripts, if used - hooks.server.ts contains your application's hooks static Any static assets that should be served as-is, like robots.txt or favicon.png, go in here. svelte.config.js This file contains your Svelte and SvelteKit configuration. tsconfig.json Since SvelteKit relies on certain configuration being set a specific way, it generates its own .svelte-kit/tsconfig.json file, which your own config extends. vite.config.js A SvelteKit project is really just a Vite project that uses the @sveltejs/kit/vite plugin, along with any other Vite configuration. Routing To get a deep dive of how routing works with SvelteKit, please check out this article. SCSS SvelteKit supports a number of CSS preprocessors. For people who are new to Svelte or SvelteKit, the syntax for using SCSS or SASS is simple, just need to add the lang="sass" attribute to the style tag. ` ` Then add SCSS support with the svelte-preprocess package. ` Why SCSS and not Tailwind? Tailwind CSS has been used by several other starter kits. We otherwise decided to go with SCSS as the syntax is simple and easily understood by even beginners. Vitest Test Driven Development (TDD) is one of the best ways to ensure your code works like it's supposed to work. It can also help you create reliable builds during continuous deployments. Vitest is an up-and-coming testing framework which has similar functionality to Jest. Since we are using Vite as our build tool for Svelte in this kit, Vitest has very good integration with Vite, and offers a similar testing environment without needing extra configuration. To test Svelte components that seemed to be hard to test. Such as two-way bindings, name slots, Context API, etc., we need to add more configuration. We added @testing-library/svelte, jsdom and @testing-library/jest-dom that allow for similar functionality as Jest. ` We ensured the $lib alias is supported in our tests by resolving the alias in our vite.config.ts. We also added a setupTest.ts to add @testing-library/jest-dom matchers & mocks of SvelteKit modules. ` ` If you want to see some test recipes you can use on your SvelteKit projects, check out our SvelteKit-SCSS Github showcase. Storybook Like many of the other starter.dev kits, the SvelteKit starter uses Storybook to interactively view and build components in isolation. For more information on Storybook and SvelteKit visit the article. Linting ESLint and Prettier are useful tools for keeping the project neat and consistent among multiple contributors. To quickly format your project, run: ` Running ESLint and Prettier as part of your git workflow is important because it helps you fail fast. This helps us, as contributors, to have a more consistent production codebase. We achieved this in our SvelteKit-SCSS Github showcase with the help of Husky, lint-staged and Prettier. How does lint-staged work? It's specifically designed to work on "staged" files, which are files you've changed or created, but haven't yet committed to your project. Working on staged files limits the number of files you need to lint at any given time, and makes the workflow faster. We configured lint-staged in our package.json. This runs Prettier pre-commit, and ensures the code is up to our ESLint standards. ` The commands you configure will run "pre-commit". As you're attempting to commit files to your project you'll see ESLint run in your terminal. Once it's done you may have successfully committed, or find yourself with linting errors you need to fix before you're able to commit the code. This works hand-in-hand with husky. Husky uses distinct bash files with filenames that match the workflow step they correspond to, e.g. "pre-commit". ` Running ESLint, or Prettier as part of your git workflow is important because it helps you fail fast, which helps contributors have a more consistent production codebase. Conclusion SvelteKit is a relatively new and novel framework. The structure represents our best judgment of how a basic SvelteKit application should be. We welcome everyone to take a look, and contribute back to the SvelteKit-SCSS and our SvelteKit-SCSS Github showcase if you have any improvements that you would like to propose!...

Apr 12, 2023

7 mins

SvelteCSS

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

In this episode of Leadership Exchange, host Rob Ocel chats with Jerry Reghunadh, Senior Director of Enterprise Architecture at Data Nimbus, about leadership, AI adoption, and data-driven decision-making. Jerry shares his career journey, insights on leveraging tools like ChatGPT and Copilot, and strategies for building effective data pipelines. They explore how companies can avoid "analysis paralysis," adopt AI strategically, and evaluate new technologies to solve real-world problems. Tune in for practical advice on aligning innovation with business goals and staying competitive in a rapidly evolving tech landscape. Chapters 00:00 – Introduction 00:31 – Jerry’s Leadership Journey 02:01 – Discussing AI in Leadership 03:59 – Experimenting with AI Tools 06:24 – Overcoming Analysis Paralysis 09:18 – Importance of Early AI Adoption 13:12 – AI’s Impact on Efficiency 14:30 – Sponsor Message 16:26 – Setting Realistic Goals for AI 19:41 – Data Management and AI 23:09 – Is AI Just a Fad? 27:22 – Testing New Technologies 29:56 – Final Thoughts on AI 30:25 – Connect with Jerry 30:44 – Closing Remarks 31:20 – Outro Follow Jerry on Social Media Linkedin: https://www.linkedin.com/in/jerrymannel/ Sponsored by This Dot: thisdot.co...

Nov 18, 2024

1 min

AIEngineering Leadership

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Integrating Storybook with SvelteKit, TypeScript, and SCSS

Introduction

Zero-config set up

Project Structure

Add SCSS support

Add $lib alias support

Creating Stories

Conclusion

Ian Sam Mungai

You might also like

A Deep Dive into SvelteKit's Rendering Techniques

Harnessing the Power of Threlte - Building Reactive Three.js Scenes in Svelte

Introducing the All New SvelteKit and SCSS Kit for starter.dev

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

Let's innovate together!

You might also like

A Deep Dive into SvelteKit's Rendering Techniques

Harnessing the Power of Threlte - Building Reactive Three.js Scenes in Svelte

Introducing the All New SvelteKit and SCSS Kit for starter.dev

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh