You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I assume they were accidentally left there because they used to be separate lines each with their own `>` at the beginning of the line, but whoever collapsed them into one line forgot to remove the extra arrow.
Whatever the case is, this commit removes (probably) all of these leftover `>` symbols.
Copy file name to clipboardExpand all lines: documentation/docs/07-misc/07-v5-migration-guide.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -58,10 +58,10 @@ A `$:` statement could also be used to create side effects. In Svelte 5, this is
58
58
>
59
59
> -`$:` only updated directly before rendering, which meant you could read stale values in-between rerenders
60
60
> -`$:` only ran once per tick, which meant that statements may run less often than you think
61
-
> -`$:` dependencies were determined through static analysis of the dependencies. This worked in most cases, but could break in subtle ways during a refactoring where dependencies would be > for example moved into a function and no longer be visible as a result
62
-
> -`$:` statements were also ordered by using static analysis of the dependencies. In some cases there could be ties and the ordering would be wrong as a result, needing manual > interventions. Ordering could also break while refactoring code and some dependencies no longer being visible as a result.
61
+
> -`$:` dependencies were determined through static analysis of the dependencies. This worked in most cases, but could break in subtle ways during a refactoring where dependencies would be for example moved into a function and no longer be visible as a result
62
+
> -`$:` statements were also ordered by using static analysis of the dependencies. In some cases there could be ties and the ordering would be wrong as a result, needing manual interventions. Ordering could also break while refactoring code and some dependencies no longer being visible as a result.
63
63
>
64
-
> Lastly, it wasn't TypeScript-friendly (our editor tooling had to jump through some hoops to make it valid for TypeScript), which was a blocker for making Svelte's reactivity model truly > universal.
64
+
> Lastly, it wasn't TypeScript-friendly (our editor tooling had to jump through some hoops to make it valid for TypeScript), which was a blocker for making Svelte's reactivity model truly universal.
65
65
>
66
66
> `$derived` and `$effect` fix all of these by
67
67
>
@@ -429,7 +429,7 @@ In Svelte 4, you would pass data to a `<slot />` and then retrieve it with `let:
429
429
> - the `let:` syntax was confusing to many people as it _creates_ a variable whereas all other `:` directives _receive_ a variable
430
430
> - the scope of a variable declared with `let:` wasn't clear. In the example above, it may look like you can use the `item` slot prop in the `empty` slot, but that's not true
431
431
> - named slots had to be applied to an element using the `slot` attribute. Sometimes you didn't want to create an element, so we had to add the `<svelte:fragment>` API
432
-
> - named slots could also be applied to a component, which changed the semantics of where `let:` directives are available (even today us maintainers often don't know which way around it > works)
432
+
> - named slots could also be applied to a component, which changed the semantics of where `let:` directives are available (even today us maintainers often don't know which way around it works)
433
433
>
434
434
> Snippets solve all of these problems by being much more readable and clear. At the same time they're more powerful as they allow you to define sections of UI that you can render _anywhere_, not just passing them as props to a component.
0 commit comments