{"id":3067,"date":"2024-07-19T13:40:23","date_gmt":"2024-07-19T18:40:23","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=3067"},"modified":"2024-08-11T17:15:59","modified_gmt":"2024-08-11T22:15:59","slug":"introducing-svelte-5","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/introducing-svelte-5\/","title":{"rendered":"Introducing Svelte 5"},"content":{"rendered":"\n

Svelte<\/a> has always been a delightful, simple, and fun framework to use. It’s a framework that’s always prioritized developer experience (DX), while producing a light and fast result with minimal JavaScript. It achieves this nice DX by giving users dirt simple idioms and a required compiler that makes everything work. Unfortunately, it used to be fairly easy to break Svelte’s reactivity. It doesn’t matter how fast a website is if it’s broken.<\/p>\n\n\n\n

These reliability problems with reactivity are gone in Svelte 5.<\/p>\n\n\n\n

In this post, we’ll get into the exciting Svelte 5 release (in Beta at the time of this writing). Svelte is the latest framework to add signals<\/strong> to power their reactivity. Svelte is now every bit as capable of handling robust web applications, with complex state, as alternatives like React and Solid. Best of all, it achieved this with only minimal hits to DX. It’s every bit as fun and easy to use as it was, but it’s now truly reliable, while still producing faster and lighter sites.<\/p>\n\n\n

\n
\n

Article Series<\/h3>\n <\/header>\n
\n
    \n
  1. \n Introducing Svelte 5<\/a>\n <\/li>\n
  2. \n Snippets in Svelte 5<\/a>\n <\/li>\n
  3. \n Fine-Grained Reactivity in Svelte 5<\/a>\n <\/li>\n <\/ol>\n <\/div>\n<\/div>\n\n\n\n

    Let’s jump in!<\/p>\n\n\n\n

    The Plan<\/h2>\n\n\n\n

    Let’s go through various pieces of Svelte, look at the “old” way, and then see how Svelte 5 changes things for the better. We’ll cover: <\/p>\n\n\n\n

      \n
    1. State<\/a><\/li>\n\n\n\n
    2. Props<\/a><\/li>\n\n\n\n
    3. Effects<\/a><\/li>\n<\/ol>\n\n\n\n

      If you find this helpful, let me know, as I’d love to cover snippets and Svelte’s exciting new fine-grained reactivity.<\/p>\n\n\n\n

      As of this writing, Svelte 5 is late in the Beta phase. The API should be stable, although it’s certainly possible some new things might get added.<\/p>\n\n\n\n

      The docs are also still in beta, so here’s a preview URL for them<\/a>. Svelte 5 might<\/em> be released when you read this, at which point these docs will be on the main Svelte page. If you’d like to see the code samples below in action, you can find them in this repo<\/a>.<\/p>\n\n\n\n

      State<\/h2>\n\n\n\n

      Effectively managing state is probably the most crucial task for any web framework, so let’s start there.<\/p>\n\n\n\n

      State used to be declared with regular, plain old variable declarations, using let<\/code>.<\/p>\n\n\n

      let<\/span> value = 0<\/span>;<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Derived state was declared with a quirky, but technically valid JavaScript syntax of $:<\/code>. For example:<\/p>\n\n\n
      let<\/span> value = 0<\/span>;\n$: doubleValue = value * 2<\/span>;<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Svelte’s compiler would (in theory) track changes to value<\/code>, and update doubleValue<\/code> accordingly. I say in theory<\/em> since, depending on how creatively you used value<\/code>, some of the re-assignments might not make it to all of the derived state that used it.<\/p>\n\n\n\n
      You could also put entire code blocks after $:<\/code> and run arbitrary code. Svelte would look at what you were referencing inside the code block, and re-run it when those things changed.<\/p>\n\n\n
      $: {\n  console<\/span>.log(\"Value is \"<\/span>, value);\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Stores<\/h3>\n\n\n\n
      Those variable declarations, and the special $:<\/code> syntax was limited to Svelte components. If you wanted to build some portable state you could define anywhere, and pass around, you’d use a store<\/a>.<\/p>\n\n\n\n
      We won’t go through the whole API, but here’s a minimal example of a store in action. We’ll define a piece of state that holds a number, and, based on what that number is at anytime, spit out a label indicating whether the number is even or odd. It’s silly, but it should show us how stores work.<\/p>\n\n\n
      import<\/span> { derived, writable } from<\/span> \"svelte\/store\"<\/span>;\n\nexport<\/span> function<\/span> createNumberInfo<\/span>(initialValue: number = 0<\/span><\/span>) <\/span>{\n  const<\/span> value = writable(initialValue);\n\n  const<\/span> derivedInfo = derived(value, value => {\n    return<\/span> {\n      value,\n      label<\/span>: value % 2<\/span> ? \"Odd number\"<\/span> : \"Even number\"<\/span>,\n    };\n  });\n\n  return<\/span> {\n    update(newValue: number) {\n      value.set(newValue);\n    },\n    numberInfo<\/span>: derivedInfo,\n  };\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Writable stores exist to write values to. Derived<\/em> stores take one or more other<\/em> stores, read their current values, and project a new payload. If you want to provide a mechanism to set a new value, close over what you need to. To consume a store’s value, prefix it with a $<\/code> in a Svelte component. It’s not shown here, but there’s also a subscribe<\/code> method on stores, and a get<\/code> import. If the store returns an object with properties, you can either “dot through” to them, or you can use a reactive assignment ($:<\/code>) to get those nested values. The example below shows both, and this distinction will come up later when we talk about interoperability between Svelte 4 and 5.<\/p>\n\n\n
      <script<\/span> lang<\/span>=\"ts\"<\/span>><\/span>\n  import<\/span> { createNumberInfo } from<\/span> '.\/numberInfoStore'<\/span>;\n\n  let<\/span> store = createNumberInfo(0<\/span>);\n\n  $: ({ numberInfo, update } = store);\n  $: ({ label, value } = $numberInfo);\n<\/span><\/script<\/span>><\/span>\n\n<div<\/span> class<\/span>=\"flex flex-col gap-2 p-5\"<\/span>><\/span>\n  <span<\/span>><\/span>{$numberInfo.value}<\/span<\/span>><\/span>\n  <span<\/span>><\/span>{$numberInfo.label}<\/span<\/span>><\/span>\n  <hr<\/span> \/><\/span>\n  <span<\/span>><\/span>{value}<\/span<\/span>><\/span>\n  <span<\/span>><\/span>{label}<\/span<\/span>><\/span>\n\n  <button<\/span> onclick<\/span>={()<\/span> =><\/span> update($numberInfo.value + 1)}>\n    Increment count\n  <\/button<\/span>><\/span>\n<\/div<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      This was the old<\/em> Svelte.<\/p>\n\n\n\n
      This is a post on the new<\/em> Svelte, so let’s turn our attention there.<\/p>\n\n\n\n
      State in Svelte 5<\/h2>\n\n\n\n
      Things are substantially simpler in Svelte 5. Pretty much everything is managed by something new called “runes.” Let’s see what that means.<\/p>\n\n\n\n
      Runes<\/h3>\n\n\n\n
      Svelte 5 joins the increasing number of JavaScript frameworks that use the concept of signals<\/em>. There is a new feature called runes<\/em> and under the covers they use signals. These accomplish a wide range of features from state to props and even side effects. Here’s a good introduction to runes<\/a>.<\/p>\n\n\n\n
      To create a piece of state, we use the $state<\/code> rune. You don’t import it, you just use it \u2014 it’s part of the Svelte language.<\/p>\n\n\n
      let<\/span> count = $state(0<\/span>);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      For values with non-inferable types, you can provide a generic<\/p>\n\n\n
      let<\/span> currentUser = $state<User | null<\/span>>(null<\/span>);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      What if you want to create some derived state? Before we did:<\/p>\n\n\n
      $: countTimes2 = count * 2<\/span>;<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      In Svelte 5 we use the $derived<\/code> rune.<\/p>\n\n\n
      let<\/span> countTimes2 = $derived(count * 2<\/span>);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Note that we pass in a raw expression<\/em>. Svelte will run it, see what it depends on, and re-run it as needed. There’s also a $derived.by<\/code> rune if you want to pass an actual function.<\/p>\n\n\n\n
      If you want to use these state values in a Svelte template, you just use them<\/em>. No need for special $<\/code> syntax to prefix the runes like we did with stores. You reference the values in your templates, and they update as needed.<\/p>\n\n\n\n
      If you want to update<\/em> a state value, you assign to it:<\/p>\n\n\n
      count = count + 1<\/span>;\n\/\/ or count++;<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      What about stores?<\/h3>\n\n\n\n
      We saw before that defining portable state outside of components was accomplished via stores. Stores are not deprecated in Svelte 5, but there’s a good chance they’re on their way out of the framework. You no longer need them, and they’re replaced with what we’ve already seen<\/em>. That’s right, the $state<\/code> and $derived<\/code> runes we saw before can be defined outside of components in top-level TypeScript (or JavaScript) files. Just be sure to name your file with a .svelte.ts<\/code> extension, so the Svelte compiler knows to enable runes in these files. Let’s take a look!<\/p>\n\n\n\n
      Let’s re-implement our number \/ label code from before, in Svelte 5. This is what it looked like with stores:<\/p>\n\n\n
      import<\/span> { derived, writable } from<\/span> \"svelte\/store\"<\/span>;\n\nexport<\/span> function<\/span> createNumberInfo<\/span>(initialValue: number = 0<\/span><\/span>) <\/span>{\n  const<\/span> value = writable(initialValue);\n\n  const<\/span> derivedInfo = derived(value, value => {\n    return<\/span> {\n      value,\n      label<\/span>: value % 2<\/span> ? \"Odd number\"<\/span> : \"Even number\"<\/span>,\n    };\n  });\n\n  return<\/span> {\n    update(newValue: number) {\n      value.set(newValue);\n    },\n    numberInfo<\/span>: derivedInfo,\n  };\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Here it is with runes:<\/p>\n\n\n
      export<\/span> function<\/span> createNumberInfo<\/span>(initialValue: number = 0<\/span><\/span>) <\/span>{\n  let<\/span> value = $state(initialValue);\n  let<\/span> label = $derived(value % 2<\/span> ? \"Odd number\"<\/span> : \"Even number\"<\/span>);\n\n  return<\/span> {\n    update(newValue: number) {\n      value = newValue;\n    },\n    get<\/span> value() {\n      return<\/span> value;\n    },\n    get<\/span> label() {\n      return<\/span> label;\n    },\n  };\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      It’s 3 lines shorter, but more importantly, much<\/em> simpler. We declared our state. We computed our derived state. And we send them both back, along with a method that updates our state.<\/p>\n\n\n\n
      You may be wondering why we did this:<\/p>\n\n\n
        get<\/span> value() {\n    return<\/span> value;\n  },\n  get<\/span> label() {\n    return<\/span> label;\n  }<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      rather than just referencing those properties. The reason is that reading<\/em> that state, at any given point in time, evaluates the state rune, and, if we’re reading it in a reactive context (like a Svelte component binding, or inside of a $derived<\/code> expression), then a subscription is set up to update any time that piece of state is updated. If we had done it like this:<\/p>\n\n\n
      \/\/ this won't work<\/span>\nreturn<\/span> {\n  update(newValue: number) {\n    value = newValue;\n  },\n  value,\n  label,\n};<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      That wouldn’t have worked because those value<\/code> and label<\/code> pieces of state would be read and evaluated right there<\/em> in the return value, with those raw values getting injected into that object. They would not be reactive, and they would never update.<\/p>\n\n\n\n
      That’s about it! Svelte 5 ships a few universal state primitives which can be used outside of components and easily constructed into larger reactive structures. What’s especially exciting is that Svelte’s component bindings are also updated, and now support fine-grained reactivity that didn\u2019t used to exist.<\/p>\n\n\n\n
      Props<\/h2>\n\n\n\n
      Defining state inside of a component isn’t too useful if you can’t pass it on to other components as props. Props are also reworked in Svelte 5 in a way that makes them simpler, and also, as we’ll see, includes a nice trick to make TypeScript integration more powerful.<\/p>\n\n\n\n
      Svelte 4 props were another example of hijacking existing JavaScript syntax to do something unrelated. To declare a prop on a component, you’d use the export<\/code> keyword. It was weird, but it worked.<\/p>\n\n\n
      \/\/ ChildComponent.svelte\n<script<\/span> lang<\/span>=\"ts\"<\/span>><\/span>\n  export<\/span> let<\/span> name: string;\n  export<\/span> let<\/span> age: number;\n  export<\/span> let<\/span> currentValue: string;\n<\/span><\/script<\/span>><\/span>\n\n<div<\/span> class<\/span>=\"flex flex-col gap-2\"<\/span>><\/span>\n  {name} {age}\n  <input<\/span> bind:value<\/span>={currentValue}<\/span> \/><\/span>\n<\/div<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      This component created three props. It also bound the currentValue<\/code> prop into the <input><\/code>, so it would change as the user typed. Then to render this component, we’d do something like this:<\/p>\n\n\n
      <script<\/span> lang<\/span>=\"ts\"<\/span>><\/span>\n  import<\/span> ChildComponent from<\/span> \".\/ChildComponent.svelte\"<\/span>;\n\n  let<\/span> currentValue = \"\"<\/span>;\n<\/span><\/script<\/span>><\/span>\n\nCurrent value in parent: {currentValue}\n<ChildComponent<\/span> name<\/span>=\"Bob\"<\/span> age<\/span>={20}<\/span> bind:currentValue<\/span> \/><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      This is Svelte 4, so let currentValue = ''<\/code> is a piece of state that can change. We pass props for name and age, but we also have bind:currentValue<\/code> which is a shorthand for bind:currentValue={currentValue}<\/code>. This creates a two-way binding<\/em>. As the child changes the value of this prop, it propagates the change upward, to the parent. This is a very cool feature of Svelte, but it’s also easy to misuse, so exercise caution.<\/p>\n\n\n\n
      If we type in the ChildComponent’s <input><\/code>, we’ll see currentValue<\/code> update in the parent component.<\/p>\n\n\n\n
      Svelte 5 version<\/h3>\n\n\n\n
      Let’s see what these props look like in Svelte 5.<\/p>\n\n\n
      <script<\/span> lang<\/span>=\"ts\"<\/span>><\/span>\n  type Props = {\n    name<\/span>: string;\n    age: number;\n    currentValue: string;\n  };\n\n  let<\/span> { age, name, currentValue = $bindable() }: Props = $props();\n<\/span><\/script<\/span>><\/span>\n\n<div<\/span> class<\/span>=\"flex flex-col gap-2\"<\/span>><\/span>\n  {name} {age}\n  <input<\/span> bind:value<\/span>={currentValue}<\/span> \/><\/span>\n<\/div<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      The props are defined via the $props<\/code> rune, from which we destructure the individual values.<\/p>\n\n\n
      let<\/span> { age, name, currentValue = $bindable() }: Props = $props();<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
      We can apply typings directly to the destructuring expression. In order to indicate that a prop can be<\/em> (but doesn’t have to be) bound to the parent, like we saw above, we use the $bindable<\/code> rune, like this<\/p>\n\n\n
       = $bindable()<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      If you want to provide a default value, assign it to the destructured value. To assign a default value to a bindable prop, pass that value to the $bindable<\/code> rune.<\/p>\n\n\n
      let<\/span> { age = 10<\/span>, name = \"foo\"<\/span>, currentValue = $bindable(\"bar\"<\/span>) }: Props = $props();<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
      But wait, there’s more!<\/h3>\n\n\n\n
      One of the most exciting changes to Svelte’s prop handling is the improved TypeScript integration. We saw that you can assign types, above. But what if we want to do something like this (in React)<\/p>\n\n\n
      type<\/span> Props<T> = {\n  items: T[];\n  onSelect: (item<\/span>: T<\/span><\/span>) =><\/span> void<\/span>;\n};\nexport<\/span> const<\/span> AutoComplete = <T,>(props<\/span>: Props<\/span><T<\/span>><\/span>) =><\/span> {\n  return<\/span> null<\/span>;\n};<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
      We want a React component that receives an array of items, as well as a callback that takes a single item (of the same type). This works in React. How would we do it in Svelte?<\/p>\n\n\n\n
      At first, it looks easy.<\/p>\n\n\n
      <script<\/span> lang<\/span>=\"ts\"<\/span>><\/span>\n  type Props<T> = {\n    items<\/span>: T[];\n    onSelect: (item: T<\/span>) =><\/span> void<\/span>;\n  };\n\n  let<\/span> { items, onSelect }: Props<T> = $props();\n  \/\/         Error here _________^<\/span>\n<\/span><\/script<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      The first T<\/code> is a generic parameter<\/em>, which is defined as part of the Props<\/code> type. This is fine. The problem is, we need to instantiate that generic type with an actual value for T when we attempt to use it in the destructuring. The T<\/code> that I used there is undefined. It doesn’t exist. TypeScript has no idea what that T<\/code> is because it hasn’t been defined.<\/p>\n\n\n\n
      What changed?<\/h3>\n\n\n\n
      Why did this work so easily with React? The reason is, React components are functions<\/em>. You can define a generic function, and when you call it<\/em> TypeScript will infer<\/em> (if it can) the values of its generic types. It does this by looking at the arguments you pass to the function. With React, rendering<\/em> a component is conceptually the same as calling it, so TypeScript is able to look at the various props you pass, and infer the generic types as needed.<\/p>\n\n\n\n
      Svelte components are not functions. They’re a proprietary bit of code thrown into a .svelte<\/code> file that the Svelte compiler turns into something useful. We do still render Svelte components, and TypeScript could easily look at the props we pass, and infer back the generic types as needed. The root of the problem, though, is that we haven’t (yet) declared any generic types that are associated with the component itself<\/em>. With React components, these are the same generic types we declare for any function. What do we do for Svelte?<\/p>\n\n\n\n
      Fortunately, the Svelte maintainers thought of this. You can declare generic types for the component itself with the generics<\/code> attribute on the <script><\/code> tag at the top of your Svelte component:<\/p>\n\n\n
      <script<\/span> lang<\/span>=\"ts\"<\/span> generics<\/span>=\"T\"<\/span>><\/span>\n  type Props<T> = {\n    items<\/span>: T[];\n    onSelect: (item: T<\/span>) =><\/span> void<\/span>;\n  };\n\n  let<\/span> { items, onSelect }: Props<T> = $props();\n<\/span><\/script<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      You can even define constraints on your generic arg:<\/p>\n\n\n
      <script<\/span> lang<\/span>=\"ts\"<\/span> generics<\/span>=\"T extends { name: string }\"<\/span>><\/span>\n  type Props<T> = {\n    items<\/span>: T[];\n    onSelect: (item: T<\/span>) =><\/span> void<\/span>;\n  };\n\n  let<\/span> { items, onSelect }: Props<T> = $props();\n<\/span><\/script<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      TypeScript will enforce this. If you violate that constraint like this:<\/p>\n\n\n
      <script<\/span> lang<\/span>=\"ts\"<\/span>><\/span>\n  import<\/span> AutoComplete from<\/span> \".\/AutoComplete.svelte\"<\/span>;\n\n  let<\/span> items = [{ name<\/span>: \"Adam\"<\/span> }, { name<\/span>: \"Rich\"<\/span> }];\n  let<\/span> onSelect = (item: { id: number }<\/span>) =><\/span> {\n    console<\/span>.log(item.id);\n  };\n<\/span><\/script<\/span>><\/span>\n\n<div<\/span>><\/span>\n  <AutoComplete<\/span> {items<\/span>} {onSelect<\/span>} \/><\/span>\n<\/div<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      TypeScript will let you know:<\/p>\n\n\n\n
      Type '(item: { id: number; }) => void' is not assignable to type '(item: { name: string; }) => void'. Types of parameters 'item' and 'item' are incompatible.

      Property 'id' is missing in type '{ name: string; }' but required in type '{ id: number; }'.<\/pre>\n\n\n\n
      Effects<\/h2>\n\n\n\n
      Let’s wrap up with something comparatively easy: side effects. As we saw before, briefly, in Svelte 4 you could run code for side effects inside of $:<\/code> reactive blocks<\/p>\n\n\n
      $: {\n  console<\/span>.log(someStateValue1, someStateValue2);\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      That code would re-run when either of those values changed.<\/p>\n\n\n\n
      Svelte 5 introduces the $effect<\/code> rune. This will run after state has changed, and been applied to the dom. It is for side effects<\/em>. Things like resetting the scroll position after state changes. It is not<\/em> for synchronizing state. If you’re using the $effect<\/code> rune to synchronize state, you’re probably doing something wrong (the same goes for the useEffect<\/code> hook in React).<\/p>\n\n\n\n
      The code is pretty anti-climactic.<\/p>\n\n\n
      $effect(()<\/span> =><\/span> {\n  console<\/span>.log(\"Current count is \"<\/span>, count);\n});<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      When this code first starts, and anytime count changes, you’ll see this log. To make it more interesting, let’s pretend we have a current timestamp value that auto-updates:<\/p>\n\n\n
      let<\/span> timestamp = $state(+new<\/span> Date<\/span>());\nsetInterval(()<\/span> =><\/span> {\n  timestamp = +new<\/span> Date<\/span>();\n}, 1000<\/span>);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      We want to include that value when we log, but we don’t<\/em> want our effect to run whenever our timestamp changes; we only want it to run when count changes. Svelte provides an untrack<\/code> utility for that<\/p>\n\n\n
      import<\/span> { untrack } from<\/span> \"svelte\"<\/span>;\n\n$effect(()<\/span> =><\/span> {\n  let<\/span> timestampValue = untrack(()<\/span> =><\/span> timestamp);\n  console<\/span>.log(\"Current count is \"<\/span>, count, \"at\"<\/span>, timestampValue);\n});<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Interop<\/h2>\n\n\n\n
      Massive upgrades where an entire app is updated to use a new framework version’s APIs are seldom feasible, so it should come as no surprise that Svelte 5 continues to support Svelte 4. You can upgrade your app incrementally. Svelte 5 components can render Svelte 4 components, and Svelte 4 components can render Svelte 5 components. The one thing you can’t do is mix and match within a single component. You cannot use reactive assignments $:<\/code> in the same component that’s using Runes (the Svelte compiler will remind you if you forget).<\/p>\n\n\n\n
      Since stores are not yet deprecated, they can continue to be used in Svelte 5 components. Remember the createNumberInfo<\/code> method from before, which returned an object with a store on it? We can use it in Svelte 5. This component is perfectly valid, and works.<\/p>\n\n\n
      <script<\/span> lang<\/span>=\"ts\"<\/span>><\/span>\n  import<\/span> { createNumberInfo } from<\/span> '..\/svelte4\/numberInfoStore'<\/span>;\n\n  const<\/span> numberPacket = createNumberInfo(0<\/span>);\n\n  const<\/span> store = numberPacket.numberInfo;\n  let<\/span> junk = $state('Hello'<\/span>);\n<\/span><\/script<\/span>><\/span>\n\n<span<\/span>><\/span>Run value: {junk}<\/span<\/span>><\/span>\n<div<\/span>><\/span>Number value: {$store.value}<\/div<\/span>><\/span>\n\n<button<\/span> onclick<\/span>={()<\/span> =><\/span> numberPacket.update($store.value + 1)}>Update<\/button<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      But the rule against reactive assignments still holds; we cannot use one to destructure values off of stores when we’re in Svelte 5 components. We have to<\/em> “dot through” to nested properties with things like {$store.value}<\/code> in the binding (which always works) rather than:<\/p>\n\n\n
      $: ({ value } = $store);<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      … which generates the error of:<\/p>\n\n\n\n
      \n
      $:<\/code> is not allowed in runes mode, use $derived<\/code> or $effect<\/code> instead<\/p>\n<\/blockquote>\n\n\n\n
      The error is even clear enough to give you another alternative to inlining those nested properties, which is to create a $derived<\/code> state:<\/p>\n\n\n
      let<\/span> value = $derived($store.value);\n\/\/ or let { value } = $derived($store);<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Personally I’m not a huge fan of mixing the new $derived<\/code> primitive with the old Svelte 4 syntax of $store<\/code>, but that’s a matter of taste.<\/p>\n\n\n\n
      Parting thoughts<\/h2>\n\n\n\n
      Svelte 5 has shipped some incredibly exciting changes. We covered the new, more reliable reactivity primitives, the improved prop management with tighter TypeScript integration, and the new side effect primitive. But we haven’t come closing to covering everything. Not only are there more variations on the $state<\/code> rune, but Svelte 5 also updated it’s event handling mechanism, and even shipped an exciting new way to re-use “snippets” of HTML.<\/p>\n\n\n\n
      Svelte 5 is worth a serious look for your next project.<\/p>\n\n\n
      \n  
      \n    
      Article Series<\/h3>\n  <\/header>\n  
      \n            
        \n                      
      1. \n              Introducing Svelte 5<\/a>\n            <\/li>\n                      
      2. \n              Snippets in Svelte 5<\/a>\n            <\/li>\n                      
      3. \n              Fine-Grained Reactivity in Svelte 5<\/a>\n            <\/li>\n                  <\/ol>\n        <\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
        Svelte 5 introduces significant improvements in reactivity, state management, and prop handling, maintaining its user-friendly Developer Experience (DX). <\/p>\n","protected":false},"author":21,"featured_media":3091,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[3,161],"class_list":["post-3067","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-post","tag-javascript","tag-svelte"],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2024\/07\/Screenshot-2024-07-18-at-3.03.18%E2%80%AFPM.png?fit=1890%2C1122&ssl=1","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/3067","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/comments?post=3067"}],"version-history":[{"count":18,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/3067\/revisions"}],"predecessor-version":[{"id":3445,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/3067\/revisions\/3445"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media\/3091"}],"wp:attachment":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media?parent=3067"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/categories?post=3067"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/tags?post=3067"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}