From e09a405bc239771cd8319e5039dcf6b49b19627a Mon Sep 17 00:00:00 2001 From: Jayden W Date: Tue, 22 Oct 2024 14:46:15 -0500 Subject: [PATCH 1/2] fix: added link to tutorial --- documentation/docs/07-misc/07-v5-migration-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/docs/07-misc/07-v5-migration-guide.md b/documentation/docs/07-misc/07-v5-migration-guide.md index c6f686033a9f..e88734d8a581 100644 --- a/documentation/docs/07-misc/07-v5-migration-guide.md +++ b/documentation/docs/07-misc/07-v5-migration-guide.md @@ -23,7 +23,7 @@ In Svelte 4, a `let` declaration at the top level of a component was implicitly Nothing else changes. `count` is still the number itself, and you read and write directly to it, without a wrapper like `.value` or `getCount()`. > [!DETAILS] Why we did this -> `let` being implicitly reactive at the top level worked great, but it meant that reactivity was constrained - a `let` declaration anywhere else was not reactive. This forced you to resort to using stores when refactoring code out of the top level of components for reuse. This meant you had to learn an entirely separate reactivity model, and the result often wasn't as nice to work with. Because reactivity is more explicit in Svelte 5, you can keep using the same API in an outside the top level of components. Head to TODO LINK TO TUTORIAL to learn more. +> `let` being implicitly reactive at the top level worked great, but it meant that reactivity was constrained - a `let` declaration anywhere else was not reactive. This forced you to resort to using stores when refactoring code out of the top level of components for reuse. This meant you had to learn an entirely separate reactivity model, and the result often wasn't as nice to work with. Because reactivity is more explicit in Svelte 5, you can keep using the same API in an outside the top level of components. Head to [the tutorial](https://svelte.dev/tutorial/svelte/welcome-to-svelte) to learn more. ### $: -> $derived/$effect From 4b9d871565a03e45a0eae245eac59f22091882a3 Mon Sep 17 00:00:00 2001 From: Ben McCann <322311+benmccann@users.noreply.github.com> Date: Tue, 22 Oct 2024 19:53:23 -0700 Subject: [PATCH 2/2] Update documentation/docs/07-misc/07-v5-migration-guide.md --- documentation/docs/07-misc/07-v5-migration-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/docs/07-misc/07-v5-migration-guide.md b/documentation/docs/07-misc/07-v5-migration-guide.md index e88734d8a581..cb80b144b3b1 100644 --- a/documentation/docs/07-misc/07-v5-migration-guide.md +++ b/documentation/docs/07-misc/07-v5-migration-guide.md @@ -23,7 +23,7 @@ In Svelte 4, a `let` declaration at the top level of a component was implicitly Nothing else changes. `count` is still the number itself, and you read and write directly to it, without a wrapper like `.value` or `getCount()`. > [!DETAILS] Why we did this -> `let` being implicitly reactive at the top level worked great, but it meant that reactivity was constrained - a `let` declaration anywhere else was not reactive. This forced you to resort to using stores when refactoring code out of the top level of components for reuse. This meant you had to learn an entirely separate reactivity model, and the result often wasn't as nice to work with. Because reactivity is more explicit in Svelte 5, you can keep using the same API in an outside the top level of components. Head to [the tutorial](https://svelte.dev/tutorial/svelte/welcome-to-svelte) to learn more. +> `let` being implicitly reactive at the top level worked great, but it meant that reactivity was constrained - a `let` declaration anywhere else was not reactive. This forced you to resort to using stores when refactoring code out of the top level of components for reuse. This meant you had to learn an entirely separate reactivity model, and the result often wasn't as nice to work with. Because reactivity is more explicit in Svelte 5, you can keep using the same API in an outside the top level of components. Head to [the tutorial](/tutorial) to learn more. ### $: -> $derived/$effect