Sync svelte docs (#826)

sync svelte docs

Co-authored-by: Rich-Harris <[email protected]>

apps/svelte.dev/content/docs/svelte/03-template-syntax/06-snippet.md

@@ -169,7 +169,7 @@ Any content inside the component tags that is _not_ a snippet declaration implic
 
 ```svelte
 <!--- file: App.svelte --->
-<Button>click me<Button>
+<Button>click me</Button>
 ```
 
 ```svelte

apps/svelte.dev/content/docs/svelte/06-runtime/01-stores.md

@@ -38,6 +38,28 @@ Prior to Svelte 5, stores were the go-to solution for creating cross-component r
 - when extracting logic, it's better to take advantage of runes' universal reactivity: You can use runes outside the top level of components and even place them into JavaScript or TypeScript files (using a `.svelte.js` or `.svelte.ts` file ending)
 - when creating shared state, you can create a `$state` object containing the values you need and then manipulate said state
 
+```ts
+/// file: state.svelte.js
+export const userState = $state({
+	name: 'name',
+	/* ... */
+});
+```
+
+```svelte
+<!--- file: App.svelte --->
+<script>
+	import { userState } from './state.svelte';
+</script>
+
+<p>User name: {userState.name}</p>
+<button onclick={() => {
+	userState.name = 'new name';
+}}>
+	change name
+</button>
+```
+
 Stores are still a good solution when you have complex asynchronous data streams or it's important to have more manual control over updating values or listening to changes. If you're familiar with RxJs and want to reuse that knowledge, the `$` also comes in handy for you.
 
 ## svelte/store

apps/svelte.dev/content/docs/svelte/07-misc/02-testing.md

@@ -197,7 +197,7 @@ When writing component tests that involve two-way bindings, context or snippet p
 
 E2E (short for 'end to end') tests allow you to test your full application through the eyes of the user. This section uses [Playwright](https://playwright.dev/) as an example, but you can also use other solutions like [Cypress](https://www.cypress.io/) or [NightwatchJS](https://nightwatchjs.org/).
 
-To get start with Playwright, either let you guide by [their VS Code extension](https://playwright.dev/docs/getting-started-vscode), or install it from the command line using `npm init playwright`. It is also part of the setup CLI when you run `npx sv create`.
+To get started with Playwright, either install it via [the VS Code extension](https://playwright.dev/docs/getting-started-vscode), or install it from the command line using `npm init playwright`. It is also part of the setup CLI when you run `npx sv create`.
 
 After you've done that, you should have a `tests` folder and a Playwright config. You may need to adjust that config to tell Playwright what to do before running the tests - mainly starting your application at a certain port:
 

apps/svelte.dev/content/docs/svelte/07-misc/03-typescript.md

@@ -142,7 +142,7 @@ In case you're writing a component that wraps a native element, you may want to
 </script>
 
 <button {...rest}>
-	{@render children()}
+	{@render children?.()}
 </button>
 ```
 
@@ -156,7 +156,7 @@ Not all elements have a dedicated type definition. For those without one, use `S
 </script>
 
 <div {...rest}>
-	{@render children()}
+	{@render children?.()}
 </div>
 ```
 

apps/svelte.dev/content/docs/svelte/07-misc/07-v5-migration-guide.md

@@ -169,11 +169,11 @@ This function is deprecated in Svelte 5. Instead, components should accept _call
 
 <Pump
 	---on:---inflate={(power) => {
-		size += power---.details---;
+		size += power---.detail---;
 		if (size > 75) burst = true;
 	}}
 	---on:---deflate={(power) => {
-		if (size > 0) size -= power---.details---;
+		if (size > 0) size -= power---.detail---;
 	}}
 />
 
@@ -317,7 +317,7 @@ When spreading props, local event handlers must go _after_ the spread, or they r
 > - import the function
 > - call the function to get a dispatch function
 > - call said dispatch function with a string and possibly a payload
-> - retrieve said payload on the other end through a `.details` property, because the event itself was always a `CustomEvent`
+> - retrieve said payload on the other end through a `.detail` property, because the event itself was always a `CustomEvent`
 >
 > It was always possible to use component callback props, but because you had to listen to DOM events using `on:`, it made sense to use `createEventDispatcher` for component events due to syntactical consistency. Now that we have event attributes (`onclick`), it's the other way around: Callback props are now the more sensible thing to do.
 >

apps/svelte.dev/content/docs/svelte/98-reference/.generated/compile-errors.md

@@ -412,6 +412,12 @@ Expected whitespace
 `$host()` can only be used inside custom element component instances
 ```
 
+### illegal_element_attribute
+
+```
+`<%name%>` does not support non-event attributes or spread attributes
+```
+
 ### import_svelte_internal_forbidden
 
 ```

apps/svelte.dev/content/docs/svelte/98-reference/21-svelte-legacy.md

@@ -281,4 +281,23 @@ function trusted(
 
 
 
+## LegacyComponentType
+
+Support using the component as both a class and function during the transition period
+
+<div class="ts-block">
+
+```dts
+type LegacyComponentType = {
+	new (o: ComponentConstructorOptions): SvelteComponent;
+	(
+		...args: Parameters<Component<Record<string, any>>>
+	): ReturnType<
+		Component<Record<string, any>, Record<string, any>>
+	>;
+};
+```
+
+</div>
+
 

apps/svelte.dev/content/docs/svelte/98-reference/30-compiler-errors.md

@@ -416,6 +416,12 @@ Expected whitespace
 `$host()` can only be used inside custom element component instances
 ```
 
+### illegal_element_attribute
+
+```
+`<%name%>` does not support non-event attributes or spread attributes
+```
+
 ### import_svelte_internal_forbidden
 
 ```