DEV Community: Chris Jackson

Building a blog with Svelte: Dynamic imports For Svelte components

Chris Jackson — Wed, 17 Feb 2021 20:01:37 +0000

Dynamic imports are a really powerful JavaScript feature. Loading modules only when needed can significantly speed up the initial load of a single page application.

There is a cost, of course. Loading pages that aren't included in your initial bundle will be slower. But if you pick less popular pages to dynamically import—like account settings—most of your users will never have to pay that cost!

So how do we take advantage of dynamic imports with Svelte?

Enter `<svelte:component>`

Svelte provides a special element for rendering components dynamically, <svelte:component>! The example from the official tutorial renders different components based on a user interaction, but the fundamentals are exactly what we need!

So let's set up a quick example with a static import first:

<script>
  import About from './Routes/About.svelte'
</script>

<svelte:component this={About}>

Making it dynamic

This example isn't very useful yet. Of course, we could always render our about page using the component directly: <About />. So let's make it dynamic!

<script>
  import { onMount } from 'svelte'
  import Error404 from './Routes/Error404.svelte'

  let dynamicPage = null

  onMount(async () => {
      try {
          dynamicPage = (await import('./Routes/About.svelte')).default
      } catch (e) {
          // Handle errors if the dynamic route doesn't load:
          dynamicPage = Error404
      }
  })
</script>

<svelte:component this={dynamicPage}>

Let's break down the changes into smaller pieces, to understand what each change is doing with this dynamic route.

Initial component setup

We're using onMount to trigger the dynamic import when this component is first rendered. My blog uses page.js as a router, so these dynamic imports are triggered by page transitions, but the logic is the same.

I've also imported an error component that is available in the main bundle, just in case there's an issue with the dynamic import: import Error404 from './Routes/Error404.svelte'.

let dynamicPage = null is a little unusual, but <svelte:component> won't render if the value of this is falsy. We'll update that value once we've loaded the page contents, but initially this will stop our component from rendering any output.

You can replace null with other values, if you'd prefer. undefined, false, 0, or many other values will behave the same as null. Or you could import a loading component to indicate that this content is waiting on a network request.

Dynamically importing `About.svelte`

await import('./Routes/About.svelte') is the expression that dynamically imports the About page, but we have two challenges.

First, await will throw an exception if the promise rejects, so we need a try/catch to handle that error. In this case, we're setting dynamicPage to indicate that an error has happened: dynamicPage = Error404.

Second, import('./Routes/About.svelte') resolves to a module object, and <svelte:component> needs a component constructor. Looking at our static import, import About from './Routes/About.svelte', we can see that our component is exported as the default export from its module, once it's been bundled. Our dynamic import can access the default export directly on the resolved module: (await import('./Routes/About.svelte')).default.

Managing bundles

One challenge that's less obvious with dynamic imports is how your bundler handles components that are imported from these dynamic chunks. With my rollup config, moving to dynamic imported Svelte components created significantly more dynamic chunks than I expected!

That might make sense for your use case, but I wanted my shared components to be included in the main bundle, rather than dynamically imported. I previously split my node_modules into a separate bundle, with Rollup's manualChunks option, so let's update that config.

My shared components live in src/Components/, so we can use that directory to assign modules to chunks:

// rollup.config.js:
//...
  output: {
    //...
    manualChunks: (moduleName) => {
      if (moduleName.includes('node_modules')) {
        return 'vendor'
      }

      if (moduleName.includes('src/Components/')) {
        return 'main'
      }
    },
//...

Putting it all together

Our example dynamic About page is potentially good enough for your app. It has basic error handling, and we discussed how you'd integrate a loading indicator. But I want to show you an example that's a little bit more complex.

My App.svelte sets up a router with some static pages and some dynamically rendered posts. The paths for the dynamic posts are stored in a config object, along with some metadata and a loader function that does the dynamic import.

// posts.js
export const posts = [
    {
        path: '/svelte/dynamic-imports',
        loader: () => import('../Routes/DynamicImportsForSvelteComponents.svelte'),
        // ...
    },
    // ...
]

<!-- App.svelte -->
<script>
  import About from './Routes/About.svelte'
  import Error404 from './Routes/404.svelte'
  import Home from './Routes/Home.svelte'
  import router from 'page'
  import { posts } from './Modules/posts'

  // Default to showing About:
  let page = About
  let nextPost = null

  // Scroll to top when navigating from the bottom of a post:
  router('*', (_, next) => {
    window.scrollTo({
      top: 0,
      left: 0,
    })

    next()
  })

  // Set up a dynamic route for each post in the config object:
  posts.forEach((post, i) => {
    router(post.path, async () => {
      // Posts take a `nextPost` prop to link to more content:
      nextPost = posts[i + 1]
      try {
        page = (await post.loader()).default
      } catch (err) {
        page = Error404
      }
    })
  })

  // Set up static routes:
  router('/', () => (page = Home))
  router('/about', () => (page = About))
  router('*', () => (page = Error404))

  router.start()
</script>

<svelte:component this={page} {nextPost} />

You can see the dynamic imports in action by visiting a post on my blog. If you open up dev tools, you should see the core bundles loaded on the home page, and a small additional bundle loaded when clicking into any post. They're all around 3kB, because they include the markdown content as well as the Svelte component that renders the post, and they should cache very well as long as the content doesn't change.

Hopefully this was useful for you! If you have questions or comments, you can always find me on twitter!

Getting Value from End to End Tests

Chris Jackson — Wed, 03 Feb 2021 16:22:23 +0000

My big project for the second half of 2020 was to "fix" some of our end to end tests—to make them useful. In some ways, the project was a huge success!

We unblocked automation through our login flow, fixing some persistent flakiness from an ongoing refactor of our session management. And we built the tests into a docker image, so we could easily execute them in any of our deploy pipelines. We now run them automatically before deploying several critical services, and it only takes a single PR to integrate them with other deploys.

Despite that success, I still see a lot of challenges with these tests. And I have some advice, if you're thinking about writing your own end to end tests.

Isolate your test data

Every interesting test relies on test data. You need a predictable storefront to test adding and removing items from a shopping cart. You need a test account with payment details to test checkouts. You may be able to mock some of the data you need, or you may be able to write less specific tests for some features, but the data that backs your tests is critical.

My ideal approach would be a set of tools that set up test data before the tests are run, and tear down the data after the tests complete. But I would settle for data that's only used by the end to end testing suite.

Changing one setting on a shared test account could easily lead to hours debugging end to end test failures. If the tests block deploys, that could be a very costly delay.

Test as early as possible

We chose to test release candidates for a few of our critical services. Those deploys trigger the tests about once a day, meaning we have up to 24 hours of changes to check if the tests fail.

Running the tests as soon as possible after a change makes it a lot easier to find the change that introduced any problems. Engineers are also more likely to be available and paying attention after making a change. Especially now, when so many teammates are remote, engineers might not be available if the tests run infrequently.

Invest in monitoring and error tracking

Errors in end to end tests are very similar to errors in production. The tests generally only have access to the UI, like a user would, and problems could occur in any part of your stack.

If your end to end test fails with a request that times out, your UI might not give you enough information to find out what caused that error. But this is just like errors that happen to real users.

There are a ton of different tools and strategies for monitoring and detecting errors in production, from simple error log collection to distributed tracing solutions. And those tools will help you debug errors in your end to end tests.

Invest in the rest of your tests

This feels like a combination of my previous two suggestions, but I think it's worth calling out separately. (It's also the suggestion most likely to come up during a job interview!)

Many of the failures I've seen with end to end tests could have been caught much sooner with stronger unit or integration testing. Especially as testing tools, like Testing Library and MSW get more sophisticated.

These tests give you more consistent results, and diligent developers might even catch problems before committing them. Debugging test failures is also significantly easier when you're only testing a small piece of your full application.

Full stack tests need full stack owners

I originally stated this one to my manager as "product tests need product owners," but I think that's not actually strong enough. It's easy to think of end to end tests as "UI tests," because that's how they interact with your application.

Every team involved in the stability of your product should care about the results of your end to end tests. After all, every one of those teams could introduce a change that breaks the tests!

If the only team investigating failures is your UI team, it could take them a long time to find issues at another layer of the stack. Hopefully you've invested in error monitoring, so it's easy to find the team that should investigate!

Conclusion

I'm moving on to other projects for 2021, but the team is working on a couple of these. Maybe I'll be able to convince them to try all five.

What do you think? Have developer-driven end to end tests been beneficial for you? Or are they still too slow—or too flaky—to feel useful?

If you've got suggestions I've missed, or you just want to chat about testing, you can find me on twitter! 🙌

Building a blog with Svelte: Fetching images via CDN

Chris Jackson — Wed, 16 Dec 2020 17:30:05 +0000

Continuing along with the blog series, we're in a pretty good place right now. The main bundle is less than 10 kB of javascript over the network, and the vendor bundle is about 50 kB. Add in a few small CSS files, thanks to tailwind and some custom styles, and my blog pages are currently seeing 100s across the board on Lighthouse!

Except if I'm on a post with an image.

Netlify caching is great, but a single image file could outweigh the entire application. And using a CDN gives us some other advantages specific to hosting images, so let's set one up!

Signing up for Cloudinary

I picked Cloudinary, because I have some familiarity with their remote image fetch feature from work, and their free tier is way more than I need for the amount of traffic that my blog is currently seeing.

Once signed up for Cloudinary, all I had to do in their admin UI was configure my security settings to restrict remote image fetching to images on my domain.

Redirecting to Cloudinary on Netlify

Netlify supports proxy redirects to other services, as long as we configure our redirect with a 200 status. To enable those redirects, we just need to add a redirect config to our netlify.toml.

# Paths like `/cloudinary/imageFile.jpg` go to cloudinary
# Don't forget to swap in your username and domain:
[[redirects]]
  from = "/cloudinary/*"
  to = """\
    https://res.cloudinary.com/\
    <Cloudinary Account Name>/\
    image/fetch/\
    q_auto,f_auto/\
    https://<Your Blog Domain>/images/:splat\
  """
  status = 200

# All other URLs serve /index.html for the Svelte app:
[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

With this in place, I'll update all the image URLs in my posts to refer to /cloudinary/<imageName>.<ext>, and Netlify will proxy them via Cloudinary!

Local development support

But there's a small problem, still. Locally, my images aren't in a /cloudinary directory, so local development can't render them. They're currently located in /public/images, and I think that's a sensible location for them. So we're going to update our Rollup config to generate different image paths for local assets and built assets.

We've already used a few Rollup plugins to add features to this blog, and we're going to add one more now.

npm install --save-dev @rollup/plugin-replace

@rollup/plugin-replace will replace strings with other content during a build. And the rollup.config.js that comes with a new Svelte project already knows whether it's building for production.

We're going to use the plugin to replace __imgPath__ with the right path for each environment. That will be /images in local development, and /cloudinary on production:

// Import @rollup/plugin-import with the other imports:
import replace from '@rollup/plugin-replace'

// ...

// Add @rollup/plugin-replace to the plugins config
export default {
  input: 'src/main.js',
  output: { /* ... */ },
  plugins: [
    replace({
      __imgPath__: production ? 'cloudinary' : 'images',
    }),

    // ...

This does mean we need to make one more change to the Svelte components. Anywhere we updated to load images from /cloudinary/<fileName>.<ext> now needs to use __imgPath__/<fileName>.<ext>. Once that change is in place, local development serves local images and the Netlify deploy will serve assets from Cloudinary!

One caveat: My code actually uses a slightly different replacement snippet, but this config will process __imgPath__ in markdown, so the real one would get replaced by the same plugin in my actual build! 🤣

Cloudinary transformations

The Netlify redirect we set up applies a very basic set of transformations: q_auto,f_auto. Those flags let Cloudinary decide what quality image to serve (q_auto), and which format to serve (f_auto). Automatic format selection even serves webp images to browsers that support them!

Taken together, both of these settings help reduce the size of images without significantly affecting how they look at common image sizes for the web.

There are a ton of other transformations you can apply via URL, including cropping to fit an aspect ratio, automatically rotating, and more. These are all documented in Cloudinary's documentation, and can be applied simply by updating the Cloudinary URL in the Netlify config.

Wrapping up

My image assets are still generally larger than my blog's code, but the file size via Cloudinary is significantly smaller. And they're served with cache headers that avoid any network round trips to verify the cache, like other Netlify assets.

I may follow up by setting up a second image path for HD images, like photos that should stay high quality. And all I'll need to do is follow the same steps as above, adding a new redirect rule and a new Rollup replacement rule for local dev support!

And even if you're not using Netlify to host your blog, you can use @rollup/plugin-replace to swap out your local URL for a Cloudinary URL in production. You'll need to include the full Cloudinary fetch URL in your plugin config, and you'll need to be sure to serve the base image assets on your production domain.

Of course, how could I end this post without including at least one image? So here's a screenshot of the polaroid component I've been hacking on, rendered in dark mode, with images fetched from Cloudinary:

Do's and don't's of writing code review feedback

Chris Jackson — Wed, 09 Dec 2020 16:55:57 +0000

Code review is a core piece of many engineering workflows. Good code review practices have a big impact on code quality. They can identify bugs or testing gaps before code is shipped to users, or identify overly complex logic before it becomes tech debt. And they're one of many tools available to teach engineers about your team's technology, standards, and practices!

But if done carelessly, code review can also contribute to a toxic team culture. If feedback isn't given intentionally, it can add a lot of stress and anxiety to a process that's supposed to be helpful.

Here are some of my tips for writing PR feedback, based on my experiences and some of the mistakes I've made. Not every review or every comment should use all of them, but using them will help keep your feedback constructive and collaborative!

Include positive and negative feedback!
- ⛔ Don't go overboard with positive feedback
- ⛔ Don't leave insincere positive comments
- ✅ Do leave emoji comments for quick praise
- ✅ Do highlight things you learned as a reviewer
Keep your feedback respectful
- ⛔ Don't use dismissive language
- ⛔ Don't leave comments without content
- ⛔ Don't repeat the same comment
- ✅ Do respect different levels of expertise
Be personal
- ✅ Do offer feedback from your perspective
- ✅ Do ask questions
Be explicit
- ✅ Be explicit about why
- ✅ Be explicit about importance
Take conversations offline

Include positive and negative feedback!

PR feedback tends to focus on areas for improvement. Like functions that could have better names, missed best practices, or places that need better test coverage.

Adding comments about good code reinforces those practices, and helps cut down on feedback anxiety in the PR process.

⛔ Don't go overboard with positive feedback

Too much positive feedback can feel forced or overwhelm your other comments.

⛔ Don't leave insincere positive comments

People will be able to tell if your comments are forced or insincere. This could make them assume all your positive feedback is insincere, or make them defensive about future areas for improvement.

✅ Do leave emoji comments for quick praise

// 👍 Do:
🔥

// 👍 Do:
🎉

// 👍 Do:
🙌

Emoji responses are an easy way to call out positive contributions without putting much thought into the wording.

✅ Do highlight things you learned as a reviewer

// 👍 Do:
I've never used this function before. Thanks for sharing!

// 👍 Do:
I didn't know our library supported this function! Can you share a link to the docs?

Code reviews are a great learning tool, and not only for the code author. If you learned something new from your review, celebrate it!

Keep your feedback respectful

⛔ Don't use dismissive language

// 👎 Don't:
Why didn't you just implement your function this way? It would be so much simpler!

// 👍 Do:
Let's rewrite your function this way. I think that implementation would be easier for readers to understand!

Comments that belittle or diminish people turn code review into an antagonistic process. Staying more collaborative makes it easier for people to accept your feedback, and makes them more likely to ask you for feedback in the future.

⛔ Don't leave comments without content

// 👎 Don't:
?

// 👎 Don't:
Fix me

// 👎 Don't:
WTF?

// 👍 Do:
Looks like this debugger was left in by accident. Let's be sure to remove it before merging the PR!

These comments might be enough to raise attention to obvious issues, like a debugger left in an open PR. But they can contribute to a dismissive tone and put code authors on the defensive.

⛔ Don't repeat the same comment

// 👎 Don't:
Don't use any
Don't use any
...
Don't use any

// 👍 Do:
Typescript any is potentially dangerous, because it erases type information and could lead to subtle bugs elsewhere in the application.

I see a few instances of any in this PR. Can you update them to use stricter typing?

Repeating the same comment multiple times makes it difficult to include relevant details in each comment, and you run the risk of overwhelming your other feedback.

One or two repetitions is okay, as long as the comments have useful content.

If you are repeating feedback too many times, you should summarize your suggestion in one comment with full details. You can refer to specific examples in that comment, or add comments that link instances back to the full feedback, if needed.

✅ Do respect different levels of expertise

// 👎 Don't:
Let's reimplement this function to use this pattern.

// 👍 Do:
Let's reimplement this function to use this pattern. Check out this other example from our codebase, or these docs, and let me know if you have any questions!

Code review is one of the tools we have to teach engineers about new projects, new libraries, or new technologies. When working with someone who's learning, links to resources or examples are useful.

Be personal

Feedback is generally subjective, based on your experiences as an engineer and a reviewer. Acknowledging that makes it more clear that your feedback is based on your perspective, and not an objective requirement.

✅ Do offer feedback from your perspective

// 👎 Don't:
This pattern is hard to understand. Could we refactor to use named functions?

// 👍 Do:
I found this pattern hard to understand. If we refactored to use named functions, it'd be easier for me to read and understand what we're doing here.

Giving feedback from your perspective leaves it open to the possibility that you're missing information. Maybe there's a shared pattern in the code base that you're just not used to yet.

Giving feedback from your perspective also leaves it open to discussion and differing opinions. The whole team doesn't need to agree about code patterns or naming schemes, so absolutes aren't helpful when giving this feedback.

✅ Do ask questions

// 👍 Do:
This boolean logic is tough for me to understand. Can you explain the different conditions to me?

Maybe we can use that to break the full condition down into some helper functions.

Asking questions can lead to a clearer explanation of what some complex logic is doing. That explanation can suggest ways to simplify or refactor that aren't as obvious without being familiar with the details.

Asking questions can also help you learn, if you're reviewing code for an app or library you aren't familiar with!

Be explicit

When offering feedback, it helps to be explicit. It makes your expectations clearer to other participants, and can make your feedback more actionable.

✅ Be explicit about why

// 👎 Don't:
Don't use any.

// 👍 Do:
Typescript any is potentially dangerous, because it erases type information and could lead to subtle bugs elsewhere in the application.

Explaining why makes it clear where your feedback is coming from, especially for best practices or dangerous patterns.

Explaining why can also act as a teaching tool for your collaborators, because it gives them information about the reason your feedback is important.

If you've got docs, this is a great reason to link them!

✅ Be explicit about importance

// 👍 Do:
I'm requesting changes on this PR. Please remove these secret keys from the source code and rotate them to avoid leaks before this is deployed to production.

// 👍 Do:
As a follow up: Let's refactor this component and add more test coverage to (hopefully) prevent future regressions

// 👍 Do:
Nit: This function name may be clearer as shouldShowModal

Some feedback is critical to address before a PR is merged, like security concerns or bugs in critical flows. If your feedback calls out an issue like that, your review should Request Changes to ensure they're addressed.

Other feedback is much less urgent. If your feedback can wait until after a PR is merged, especially for an urgent change, call that out by asking for a follow up. You can also ask the author to file a ticket to track that follow up, if you want them to take some concrete action before merging their change.

Marking nits is also a good practice, to be explicit about that feedback being less important than more critical feedback. If you're making a lot of significant comments, it may even be worth omitting the nits to emphasize the more important changes.

Take conversations offline

If you've got a lot of feedback, or there's a communication gap between reviewer and author, it can be very helpful to take conversations out of GitHub.

Try pairing with the code author if they need help implementing your feedback, or schedule a quick call to discuss different options for addressing feedback. This can be especially helpful if a PR has gone through more than one round of feedback and some of your concerns aren't being addressed, or if there is a strong disagreement about the best way to address some feedback.

After discussing out of band, leave a summary in a comment on the PR. It will help remind everyone of the discussion, especially if there is more work to do before the PR is merged.

Building a blog with Svelte: Code splitting

Chris Jackson — Wed, 02 Dec 2020 16:46:10 +0000

Last week, I shared the steps I took to add Markdown support to my blog, written in Svelte. And I'm happy with how portable the Markdown content is, and how smooth the authoring experience is with livereload in my development environment.

But I do have one more concern that I want to address before I feel good about this solution.

Right now, adding content increases the size of my app bundle. The more I write, the slower my site will be!

So let's fix that with code splitting. We can keep our authoring working with static files in a git repository, and get significantly better cache performance for our assets.

Adding a vendor bundle

For the first step, we'll split out our npm modules into a separate vendor bundle. Rollup will fingerprint that file, so our users will be able to cache it as long as we don't change any of our dependencies!

We're going to use the manualChunks option in our rollup config to split our files with a custom function:

export default {
  input: 'src/main.js',
  output: {
    sourcemap: true,
    // Code Splitting requires specific module types, so we'll use EcmaScript modules:
    format: 'es',
    name: 'app',
    // Our output needs to be a directory, instead of a single file:
    dir: 'public/build/',
    manualChunks: (moduleName) => {
      // Every module whose name includes `node_modules` should be in vendor:
      if (moduleName.includes('node_modules')) {
        return 'vendor'
      }
      // Every other module will be in the chunk based on its entry point!
    },
  },

But now we have a problem. The HTML template included in the Svelte template doesn't support ES module files by default, and now rollup is generating files with a different name!

So let's fix our HTML now. We need to tell the browser that this script is an EcmaScript module with type="module", and we need to use the updated name, /build/main.js.

<!-- Before: <script defer src='/build/bundle.js'></script> -->
<script type="module" defer src='/build/main.js'></script>

With those changes, we should be able to run our site in development without any issues. Loading the page will now load two javascript files, /build/main.js and a second file /build/vendor-[hash].js.

Removing Markdown from the main bundle

Our vendor bundle should be a big performance benefit, but we still have the problem where adding Markdown content will continue to increase our app size over time.

We can fix that by using the import() function to load that content as needed, and rollup will split those chunks for us automatically.

Adding dynamic imports

We'll start by adding dynamic imports for the Markdown content to the post components:

<script>
  import { Layout, Markdown } from '../Components'
  import { onMount } from 'svelte'

  let markdown = ''

  // When we mount this component, load the markdown chunk:
  onMount(async () => {
    markdown = (await import('../Markdown/AddingMarkdownToSvelte.md')).default
  })
</script>

<Layout>
  <Markdown {markdown} />
</Layout>

One of those lines is a little odd, though: (await import('../Markdown/AddingMarkdownToSvelte.md')).default. As a side effect of loading this markdown content as an application chunk, it's been packaged as a module!

This does add a small bit of overhead into the file contents, but it's not much. And it does mean that we need to access the default export when we import the module.

Updating the `Markdown` component

The last change we need to make is to update the Markdown component to rerender when its content loads. My initial component assumed the Markdown was fixed as soon as the component was rendered, so we could just render once.

But now, we need to be able to update the Markdown content when the chunk loads, and we'll use beforeUpdate from Svelte to do that:

  import { beforeUpdate } from 'svelte'

  export let markdown = ''

  let rendered = ''

  beforeUpdate(() => {
    rendered = md.render(markdown)
  })

The component will still render the content like before: {@html rendered}, but now replacing the markdown will rerender the page.

Cross-browser compatibility

One concern to be aware of if you want to add this to your site, is that scripts with type="module" are not supported in Internet Explorer or some older phone browsers. caniuse has the full details.

If you're following along, this shouldn't be a huge concern. By default, the Svelte build is also not supported in Internet Explorer, so if this compatibility is critical for you, you've got more work to do!

Wrapping up

With all of that in place, my blog now loads only the content it needs and is set to have good cache performance for the larger vendor chunk.

My authoring workflow is still simple, mostly writing Markdown into a file with a little bit of Svelte to wire up the page.

And if I want to migrate to a CMS or build an api to serve my content, the components are ready to load that content asynchronously with only a small change! (Moving to loading posts from another source would even let me avoid creating a new route component for each post!)

These changes will be up shortly on github, and if you want to chat, you can find me on twitter!

Building a blog with Svelte: Adding Markdown

Chris Jackson — Wed, 25 Nov 2020 21:07:10 +0000

I started building a personal blog with Svelte a few weeks ago, cross posting to dev.to for more reach and community.

And it sucks!

I've been manually building content with Svelte components, to get the look and feel I want on my site. And then I have to translate those posts into Markdown for posting elsewhere.

So I'm going to build Markdown support for my Svelte site, starting with this post. I'll tell you how to add support to your Svelte site, and I'll compare the output on both platforms when I'm done!

Adding `markdown-it`

The first thing we want to do is add a library for Markdown parsing. I'm going to use markdown-it. It's seeing active development and the README has examples of rendering markdown in code, which I will need!

Step 1: Installing dependencies

markdown-it is an easy install via npm, but it does assume that you have a full node environment to fall back on. So I needed to install a few extra dependencies.

npm install --save markdown-it punycode
npm install --save-dev @rollup/plugin-json

Step 2: Updating `rollup.config.js`

With dependencies installed, we can import the library into our Svelte app and try rendering basic Markdown. But rollup is going to complain because it can't import JSON, and it needs to be configured to support adding punycode into the browser bundle.

So let's fix that now.

To support JSON, we just need to add the rollup plugin (@rollup/plugin-json) with its default settings:

// In imports:
import json from '@rollup/plugin-json'

// In rollup config:
export default {
    //...
    plugins: [
        //...
        json(),
        //...
    ]
}

And we also need to tell rollup to include the punycode version we just installed into our browser bundle:

// In plugins:
resolve({
    browser: true,
    dedupe: ['svelte'],
    // Include our installed package, instead of the built in version
    preferBuiltins: false,
}),

Step 3: Rendering some sample Markdown

With those config updates, we should now be able to render Markdown inside of our Svelte app. So let's build a Markdown component to render that content.

We'll take in our Markdown string as a prop (markdown) for now. That lets us test with a static string, and we can update the app to read Markdown from files or a CMS in the future.

And we need to use Svelte's @html feature to add our generated HTML to the page.

⚠️ Warning: Using @html with user submitted content could expose your users to an XSS vulnerability. markdown-it has documentation about its security features and recommendations, which you should read and understand if you need to support user submitted content. ⚠️

<!-- src/Markdown.svelte -->
<script>
  import MarkdownIt from 'markdown-it'

  export let markdown = ''

  // Initialize `markdown-it`
  const md = new MarkdownIt()

  // Render to an html string
  const rendered = md.render(markdown)
</script>

<!-- Render with the `@html` directive -->
<div>
  {@html rendered}
</div>

And we'll need to add our Markdown component to test:

<script>
  import Markdown from './Markdown.svelte'
</script>

<Markdown markdown="# Hello from Markdown!" />

Reading Markdown from a file

Now that we can render Markdown, we're going to set up our build to read Markdown from files. Authoring is much easier in separate files, and I can use my project's git repo for some basic versioning.

Step 4: Importing `*.md`

Our Markdown components renders content from a string, so we need to be able to read our Markdown content in that format. rollup will fail right now if we try to import an .md file, but we can fix that with another plugin: rollup-plugin-string.

npm install --save-dev rollup-plugin-string

And when we add it to rollup.config.js, we need to configure it to read .md files:

// In imports:
import { string } from 'rollup-plugin-string'

// In rollup config:
export default {
    //...
    plugins: [
        //...
        string({
            include: ['**/*.md'],
        }),
        //...
    ]
}

Step 5: Updating our test to render from a file

First, let's create a new Markdown file to test, src/example.md:

# Hello from Markdown!

We can render *text*.

And now import that markdown into your app:

<script>
  import Markdown from './Markdown.svelte'
  import exampleMarkdown from './example.md'
</script>

<Markdown markdown={exampleMarkdown} />

Supporting syntax highlighting

Basic Markdown is great, but one of the killer features for blogging as an engineer is syntax highlighting. markdown-it supports highlighting via a library, so let's add that now.

Step 6: Install `highlight.js`

highlight.js will allow us to add syntax highlighting to a wide variety of languages (including Markdown 🤣), and is bundled with a wide variety of themes we can use. And markdown-it uses it in their example, so let's start there.

npm install --save highlight.js

We don't need to update our rollup config for this step, but we will need to configure highlighting in our Markdown component:

<!-- src/Markdown.svelte -->
<script>
  import MarkdownIt from 'markdown-it'

  // NEW: Import `highlight.js`
  import hljs from 'highlight.js'

  export let markdown = ''

  // Initialize `markdown-it`
  // NEW: Configure highlight via constructor params!
  const md = new MarkdownIt({
      highlight: function (str, lang) {
      if (lang && hljs.getLanguage(lang)) {
        try {
          return hljs.highlight(lang, str).value
        } catch (e) {
          // eslint-disable-next-line no-console
          console.error('Failed to highlight string')
        }
      }
      return '' // use external default escaping
    },
  })

  // Render to an html string
  const rendered = md.render(markdown)
</script>

<!-- Render with the `@html` directive -->
<div>
  {@html rendered}
</div>

Step 7: Import `highlight.js` themes

Adding a code block to the example markdown will render a code block, but we're not currently getting any styling for our highlighting. We can import styles directly from highlight.js styles, but we'll need to update our rollup config again for this to work.

We're going to add rollup-plugin-styles to handle our CSS imports.

npm install --save-dev rollup-plugin-styles

And we can use its default configuration in rollup.config.js.

// In imports:
import styles from 'rollup-plugin-styles'

// In rollup config:
export default {
    //...
    plugins: [
        //...
        styles(),
        //...
    ]
}

Once we've done that, we can import a stylesheet from highlight.js into our Markdown component to render those styles into our site. I'm going to use a11y-light for this example, but there are lots of options you can pick, depending on your site's color scheme.

<!-- src/Markdown.svelte -->
<script>
  import MarkdownIt from 'markdown-it'
  import 'highlight.js/styles/a11y-light.css'
  // ...

Wrapping up and writing the post!

With all of these pieces in place, I can now write this blog post in Markdown! There is still some work to do, especially styling the rendered HTML to match the rest of my site. But I can create my content in Markdown and let these libraries worry about the HTML!

For a quick demo, here's a comparison of the markdown for this post rendered in my local development environment and in a draft post on dev.to:

If you want to see the final version of the rollup config, I have a completed copy of the tutorial posted on github!

And if you have suggestions for improvements, I'm happy to chat on twitter!

Building a simple theme store with Svelte

Chris Jackson — Wed, 18 Nov 2020 15:56:28 +0000

Dark mode has been gaining in popularity over the past few years, and now all of the major operating systems support a global dark theme. And a lot of major sites offer a dark mode toggle. But with modern browsers we can do better! We can use the user's OS preference to show them the color theme they prefer when they first land on our sites!

This tutorial is going to teach you how to detect a user's OS theme in CSS and JavaScript, as well as how to build a Svelte store to respond to theme changes.

Detecting dark mode in CSS

The secret to detecting a user's OS theme is the media query prefers-color-scheme. The two major options are light and dark, and we can easily use them to define CSS variables to apply these themes for an entire site.

@media (prefers-color-scheme: dark) {
  --background-color: midnightblue;
}

@media (prefers-color-scheme: light) {
  --background-color: snow;
}

Detecting dark mode in JavaScript

We can use the same media query to detect a user's OS theme in JavaScript, as well!

JavaScript supports executing any media query with window.matchMedia. The call returns a MediaQueryList object that supports two features we'll need when we build the Svelte store.

The two properties we care about are matches, for checking the result of the media query, and addListener for detecting changes.

const darkModeQuery = window.matchMedia('(prefers-color-scheme: dark)')

const darkModeEnabled = darkModeQuery.matches

darkModeQuery.addListener(event => {
    console.log('Theme changed to:', event.matches ? 'dark' : 'light')
})

Building our Svelte store

The CSS approach is very useful for a static site, but as we add components or import libraries that need to know about our theme, it becomes more important to have a single source of truth for that data in our app.

So let's build a theme store for a Svelte app!

We start by defining our writable store based on the user's OS theme when the store is first loaded:

import { writable } from 'svelte/store'

// Set up our MediaQueryList
const prefersDarkMode = window.matchMedia('(prefers-color-scheme: dark)')

// Initial theme config from current state
export const theme = writable(prefersDarkMode.matches ? 'dark' : 'light')

This is a great start, and it's probably enough for many apps, because users don't change their OS themes too often. But it's only a little bit more work to add an event listener to detect changes:

// Update the store if OS preference changes
const updateThemeOnChange = e => theme.set(e.matches ? 'dark' : 'light')
prefersDarkMode.addListener(updateThemeOnChange)

// Export a function to clean up the listener if needed
export const cleanUp = () => prefersDarkMode.removeListener(updateThemeOnChange)

Putting all of this together, we have a simple theme store that responds to OS theme changes quickly! If you want to see a demo, you can check it out on the Svelte REPL!

Caveats

There are a few small gotchas with this approach that might result in your users seeing the wrong theme.

A few browsers, including IE, do not support the media query we're using. However, nearly all browsers support matchMedia, so they should fall back to whichever theme you picked as the default. For full details, see Can I use prefers-color-scheme?.

And if you enable some privacy settings, like privacy.resistFingerprinting in Firefox, this media query will default to the light theme. For more details here, see prefers-color-scheme on MDN.

Next steps!

This simple store is only a few lines of code, thanks to the power of the prefers-color-scheme media query. So I want to leave you with some suggestions for work you could do to learn a little more!

The Svelte store I'm using here is relatively simple. We set an initial value when we create it with writable, and we can update the value with set. Can you write a React hook for this state, or implement the store in another state library?

It's great to respond to user preferences, but what if the user wants to use your app with a different theme? Can you update the store to change themes when the user pushes a button? Can you update the store so that our app theme is independent from the OS theme, after they've pushed that button?

Happy coding!

Three tips to be a better code reviewer today

Chris Jackson — Fri, 13 Nov 2020 16:35:49 +0000

As a professional software developer, code review is a big part of the job! It's often a requirement for shipping your work, and understanding code well enough to give feedback takes time.

So engineering teams often turn to automation to help reduce the cost of code reviews. Test coverage and static analysis tools help avoid bugs and vulnerabilities. Linters and formatters keep devs from spending time and energy on code style.

And these tools are great! But they miss the human aspect of professional development. With that in mind, here are three tips to help you be a better code reviewer for your team, no matter how experienced you are or what technology you use!

1. Do the tests document the code well enough?

Comments get out of date quickly. Design docs get lost. When you revisit a project, sometimes the only documentation you have is the tests.

If you have great tests, that might not be too bad. If you have no tests, it could be a disaster!

As a starting point for feedback about the tests, ask yourself these questions:

Can I call this function, use this library, or render this component using the tests as examples?
Do the tests tell me what inputs are valid?
Do the tests tell me what inputs will throw an error or have invalid results?

2. What parts of the code were the hardest to understand?

After a feature has shipped, it needs to be maintained. Eventually, someone will read this code who has never seen it before, and they'll need to understand it well enough to change it.

That person reading the code for the first time might even be you! Lots of engineers have done a git blame and realized they were the original author of the code they were just complaining about.

(from /r/ProgrammerHumor)

Thankfully, code review is a similar experience. As a reviewer, you're probably reading the code for the first time, and you don't have all the context of the code author. If any of the code was difficult to understand when you read it, offer some feedback to improve it!

Could the names be clearer, or more descriptive?
Could complex logic be broken down into utility functions?
Could the documentation be improved with a comment? Or a more targetted test case?

3. Explain why

This last one is a little different from the first two, because it's about how you give your feedback, not about what feedback you give. And it's much simpler.

When you give feedback during a code review, explain why!

If you're an expert, code review is a tool to teach other engineers. Making suggestions and explaining why is how you do that.

And if you're not teaching, explaining why helps to build empathy and open discussions about other options.

You don't have to write a novel, but even a little explanation helps. For example, This boolean logic was tough for me to follow. Can you split it into a few utility functions?

What's next?

Being great at code reviews is a skill that takes a lot of practice, and there are a ton of topics that can't be covered in a quick list like this. Some of them are technical, like language specific best practices, and some of them are interpersonal, like offering effective feedback.

But hopefully these tips will help you and your team get more value out of your code reviews!

DEV Community: Chris Jackson

Building a blog with Svelte: Dynamic imports For Svelte components

Enter <svelte:component>

Making it dynamic

Initial component setup

Dynamically importing About.svelte

Managing bundles

Putting it all together

Getting Value from End to End Tests

Isolate your test data

Test as early as possible

Invest in monitoring and error tracking

Invest in the rest of your tests

Full stack tests need full stack owners

Conclusion

Building a blog with Svelte: Fetching images via CDN

Signing up for Cloudinary

Redirecting to Cloudinary on Netlify

Local development support

Cloudinary transformations

Wrapping up

Do's and don't's of writing code review feedback

Table of Contents

Include positive and negative feedback!

⛔ Don't go overboard with positive feedback

⛔ Don't leave insincere positive comments

✅ Do leave emoji comments for quick praise

✅ Do highlight things you learned as a reviewer

Keep your feedback respectful

⛔ Don't use dismissive language

⛔ Don't leave comments without content

⛔ Don't repeat the same comment

✅ Do respect different levels of expertise

Be personal

✅ Do offer feedback from your perspective

✅ Do ask questions

Be explicit

✅ Be explicit about why

✅ Be explicit about importance

Take conversations offline

Building a blog with Svelte: Code splitting

Adding a vendor bundle

Removing Markdown from the main bundle

Adding dynamic imports

Updating the Markdown component

Cross-browser compatibility

Wrapping up

Building a blog with Svelte: Adding Markdown

Adding markdown-it

Step 1: Installing dependencies

Step 2: Updating rollup.config.js

Step 3: Rendering some sample Markdown

Reading Markdown from a file

Step 4: Importing *.md

Step 5: Updating our test to render from a file

Supporting syntax highlighting

Step 6: Install highlight.js

Step 7: Import highlight.js themes

Wrapping up and writing the post!

Building a simple theme store with Svelte

Detecting dark mode in CSS

Detecting dark mode in JavaScript

Building our Svelte store

Caveats

Next steps!

Three tips to be a better code reviewer today

1. Do the tests document the code well enough?

2. What parts of the code were the hardest to understand?

3. Explain why

What's next?

Enter `<svelte:component>`

Dynamically importing `About.svelte`

Updating the `Markdown` component

Adding `markdown-it`

Step 2: Updating `rollup.config.js`

Step 4: Importing `*.md`

Step 6: Install `highlight.js`

Step 7: Import `highlight.js` themes