docs: clean up some confusion about state management and pages. (#10553)

* Attempt cleared language in state management

A commonly returning error on Discord is related to state preservation in pages due to misunderstandings how pages relate to components in regards to reactivity

* Update documentation/docs/20-core-concepts/50-state-management.md

Co-authored-by: Willow (GHOST) <[email protected]>

* Update documentation/docs/20-core-concepts/50-state-management.md

Co-authored-by: Willow (GHOST) <[email protected]>

* some more finetuning of docs, include a quick note on lifecycles

* moved text around

* better wording

* more moving docs around

* Apply suggestions from code review

---------

Co-authored-by: Willow (GHOST) <[email protected]>
Co-authored-by: Rich Harris <[email protected]>

documentation/docs/20-core-concepts/50-state-management.md

@@ -117,7 +117,7 @@ Updating the context-based store value in deeper-level pages or components will
 
 If you're not using SSR (and can guarantee that you won't need to use SSR in future) then you can safely keep state in a shared module, without using the context API.
 
-## Component state is preserved
+## Component and page state is preserved
 
 When you navigate around your application, SvelteKit reuses existing layout and page components. For example, if you have a route like this...
 
@@ -140,7 +140,7 @@ When you navigate around your application, SvelteKit reuses existing layout and
 <div>{@html data.content}</div>
 ```
 
-...then navigating from `/blog/my-short-post` to `/blog/my-long-post` won't cause the component to be destroyed and recreated. The `data` prop (and by extension `data.title` and `data.content`) will change, but because the code isn't rerunning, `estimatedReadingTime` won't be recalculated.
+...then navigating from `/blog/my-short-post` to `/blog/my-long-post` won't cause the layout, page and any other components within to be destroyed and recreated. Instead the `data` prop (and by extension `data.title` and `data.content`) will update (as it would with any other Svelte component) and, because the code isn't rerunning, lifecycle methods like `onMount` and `onDestroy` won't rerun and `estimatedReadingTime` won't be recalculated.
 
 Instead, we need to make the value [_reactive_](https://learn.svelte.dev/tutorial/reactive-assignments):
 
@@ -155,7 +155,9 @@ Instead, we need to make the value [_reactive_](https://learn.svelte.dev/tutoria
 </script>
 ```
 
-Reusing components like this means that things like sidebar scroll state are preserved, and you can easily animate between changing values. However, if you do need to completely destroy and remount a component on navigation, you can use this pattern:
+> If your code in `onMount` and `onDestroy` has to run again after navigation you can use [afterNavigate](modules#$app-navigation-afternavigate) and [beforeNavigate](modules#$app-navigation-beforenavigate) respectively.
+
+Reusing components like this means that things like sidebar scroll state are preserved, and you can easily animate between changing values. In the case that you do need to completely destroy and remount a component on navigation, you can use this pattern:
 
 ```svelte
 {#key $page.url.pathname}