>
diff --git a/docs/getting-started/fundamentals/static-dynamic-rendering.md b/docs/getting-started/fundamentals/static-dynamic-rendering.md
index 8d199f66cccd2a..dfb6a7123b44b3 100644
--- a/docs/getting-started/fundamentals/static-dynamic-rendering.md
+++ b/docs/getting-started/fundamentals/static-dynamic-rendering.md
@@ -61,7 +61,7 @@ Dynamic blocks, which we'll explore in the following section, can specify an ini
For a practical demonstration of how this works, refer to the [Building your first block](/docs/getting-started/tutorial.md) tutorial. Specifically, the [Adding static rendering](/docs/getting-started/tutorial.md#adding-static-rendering) section illustrates how a block can have both a saved HTML structure and dynamic rendering capabilities.
-WordPress provides mechanisms like the
render_block are the
$render_callback function to alter the saved HTML of a block before it appears on the front end. These tools offer developers the capability to customize block output dynamically, catering to complex and interactive user experiences.
+WordPress provides mechanisms like the
render_block and the
render_callback function to alter the saved HTML of a block before it appears on the front end. These tools offer developers the capability to customize block output dynamically, catering to complex and interactive user experiences.
...
+```
+
+For that reason, you need to define its type manually and pass it to the `getContext` function to ensure the returned properties are correctly typed.
+
+```ts
+// Defines the types of your context.
+type MyContext = {
+ counter: number;
+};
+
+store( 'myCounterPlugin', {
+ actions: {
+ increment() {
+ // Passes it to the getContext function.
+ const context = getContext< MyContext >();
+ // Now `context` is properly typed.
+ context.counter += 1;
+ },
+ },
+} );
+```
+
+To avoid having to pass the context types over and over, you can also define a typed function and use that function instead of `getContext`.
+
+```ts
+// Defines the types of your context.
+type MyContext = {
+ counter: number;
+};
+
+// Defines a typed function. You only have to do this once.
+const getMyContext = getContext< MyContext >;
+
+store( 'myCounterPlugin', {
+ actions: {
+ increment() {
+ // Use your typed function.
+ const context = getMyContext();
+ // Now `context` is properly typed.
+ context.counter += 1;
+ },
+ },
+} );
+```
+
+That's it! Now you can access the context properties with the correct types.
+
+## Typing the derived state
+
+The derived state is data that is calculated based on the global state or local context. In the client store definition, it is defined using a getter in the `state` object.
+
+_Please, visit the [Understanding global state, local context and derived state](./undestanding-global-state-local-context-and-derived-state.md) guide to learn more about how derived state works in the Interactivity API._
+
+Following our previous example, let's create a derived state that is the double of our counter.
+
+```ts
+type MyContext = {
+ counter: number;
+};
+
+const myStore = store( 'myCounterPlugin', {
+ state: {
+ get double() {
+ const { counter } = getContext< MyContext >();
+ return counter * 2;
+ },
+ },
+ actions: {
+ increment() {
+ state.counter += 1; // This type is number.
+ },
+ },
+} );
+```
+
+Normally, when the derived state depends on the local context, TypeScript will be able to infer the correct types:
+
+```ts
+const myStore: {
+ state: {
+ readonly double: number;
+ };
+ actions: {
+ increment(): void;
+ };
+};
+```
+
+But when the return value of the derived state depends directly on some part of the global state, TypeScript will not be able to infer the types because it will claim that it has a circular reference.
+
+For example, in this case, TypeScript cannot infer the type of `state.double` because it depends on `state.counter`, and the type of `state` is not completed until the type of `state.double` is defined, creating a circular reference.
+
+```ts
+const { state } = store( 'myCounterPlugin', {
+ state: {
+ counter: 0,
+ get double() {
+ // TypeScript can't infer this return type because it depends on `state`.
+ return state.counter * 2;
+ },
+ },
+ actions: {
+ increment() {
+ state.counter += 1; // This type is now unknown.
+ },
+ },
+} );
+```
+
+In this case, depending on your TypeScript configuration, TypeScript will either warn you about a circular reference or simply add the `any` type to the `state` property.
+
+However, solving this problem is easy; we simply need to manually provide TypeScript with the return type of that getter. Once we do that, the circular reference disappears, and TypeScript can once again infer all the `state` types.
+
+```ts
+const { state } = store( 'myCounterPlugin', {
+ state: {
+ counter: 1,
+ get double(): number {
+ return state.counter * 2;
+ },
+ },
+ actions: {
+ increment() {
+ state.counter += 1; // Correctly inferred!
+ },
+ },
+} );
+```
+
+These are now the correct inferred types for the previous store.
+
+```ts
+const myStore: {
+ state: {
+ counter: number;
+ readonly double: number;
+ };
+ actions: {
+ increment(): void;
+ };
+};
+```
+
+When using `wp_interactivity_state` in the server, remember that you also need to define the initial value of your derived state, like this:
+
+```php
+wp_interactivity_state( 'myCounterPlugin', array(
+ 'counter' => 1,
+ 'double' => 2,
+));
+```
+
+But if you are inferring the types, you don't need to manually define the type of the derived state because it already exists in your client's store definition.
+
+```ts
+// You don't need to type `state.double` here.
+type ServerState = {
+ state: {
+ counter: number;
+ };
+};
+
+// The `state.double` type is inferred from here.
+const storeDef = {
+ state: {
+ get double(): number {
+ return state.counter * 2;
+ },
+ },
+ actions: {
+ increment() {
+ state.counter += 1;
+ },
+ },
+};
+
+// Merges the types of the server state and the client store definition.
+type Store = ServerState & typeof storeDef;
+
+// Injects the final types when calling the `store` function.
+const { state } = store< Store >( 'myCounterPlugin', storeDef );
+```
+
+That's it! Now you can access the derived state properties with the correct types.
+
+## Typing asynchronous actions
+
+Another thing to keep in mind when using TypeScript with the Interactivity API is that asynchronous actions must be defined with generators instead of async functions.
+
+The reason for using generators in the Interactivity API's asynchronous actions is to be able to restore the scope from the initially triggered action once the asynchronous action continues its execution after yielding. But this is a syntax change only, otherwise, **these functions operate just like regular async functions**, and the inferred types from the `store` function reflect this.
+
+Following our previous example, let's add an asynchronous action to the store.
+
+```ts
+const { state } = store( 'myCounterPlugin', {
+ state: {
+ counter: 0,
+ get double(): number {
+ return state.counter * 2;
+ },
+ },
+ actions: {
+ increment() {
+ state.counter += 1;
+ },
+ *delayedIncrement() {
+ yield new Promise( ( r ) => setTimeout( r, 1000 ) );
+ state.counter += 1;
+ },
+ },
+} );
+```
+
+The inferred types for this store are:
+
+```ts
+const myStore: {
+ state: {
+ counter: number;
+ readonly double: number;
+ };
+ actions: {
+ increment(): void;
+ // This behaves like a regular async function.
+ delayedIncrement(): Promise< void >;
+ };
+};
+```
+
+This also means that you can use your async actions in external functions, and TypeScript will correctly use the async function types.
+
+```ts
+const someAsyncFunction = async () => {
+ // This works fine and it's correctly typed.
+ await actions.delayedIncrement( 2000 );
+};
+```
+
+When you are not inferring types but manually writing the types for your entire store, you can use async function types for your async actions.
+
+```ts
+type Store = {
+ state: {
+ counter: number;
+ readonly double: number;
+ };
+ actions: {
+ increment(): void;
+ delayedIncrement(): Promise< void >; // You can use async functions here.
+ };
+};
+```
+
+There's something to keep in mind when when using asynchronous actions. Just like with the derived state, if the asynchronous action needs to return a value and this value directly depends on some part of the global state, TypeScript will not be able to infer the type due to a circular reference.
+
+ ```ts
+ const { state, actions } = store( 'myCounterPlugin', {
+ state: {
+ counter: 0,
+ },
+ actions: {
+ *delayedReturn() {
+ yield new Promise( ( r ) => setTimeout( r, 1000 ) );
+ return state.counter; // TypeScript can't infer this return type.
+ },
+ },
+ } );
+ ```
+
+ In this case, just as we did with the derived state, we must manually type the return value of the generator.
+
+ ```ts
+ const { state, actions } = store( 'myCounterPlugin', {
+ state: {
+ counter: 0,
+ },
+ actions: {
+ *delayedReturn(): Generator< uknown, number, uknown > {
+ yield new Promise( ( r ) => setTimeout( r, 1000 ) );
+ return state.counter; // Now this is correctly inferred.
+ },
+ },
+ } );
+ ```
+
+ That's it! Remember that the return type of a Generator is the second generic argument: `Generator< unknown, ReturnType, unknown >`.
+
+## Typing stores that are divided into multiple parts
+
+Sometimes, stores can be divided into different files. This can happen when different blocks share the same namespace, with each block loading the part of the store it needs.
+
+Let's look at an example of two blocks:
+
+- `todo-list`: A block that displays a list of todos.
+- `add-post-to-todo`: A block that shows a button to add a new todo item to the list with the text "Read {$post_title}".
+
+First, let's initialize the global and derived state of the `todo-list` block on the server.
+
+```php
+ $todos,
+ 'filter' => 'all',
+ 'filteredTodos' => $todos,
+));
+?>
+
+
+```
+
+Now, let's type the server state and add the client store definition. Remember, `filteredTodos` is derived state, so you don't need to type it manually.
+
+```ts
+// todo-list-block/view.ts
+type ServerState = {
+ state: {
+ todos: string[];
+ filter: 'all' | 'completed';
+ };
+};
+
+const todoList = {
+ state: {
+ get filteredTodos(): string[] {
+ return state.filter === 'completed'
+ ? state.todos.filter( ( todo ) => todo.includes( 'ā
' ) )
+ : state.todos;
+ },
+ },
+ actions: {
+ addTodo( todo: string ) {
+ state.todos.push( todo );
+ },
+ },
+};
+
+// Merges the inferred types with the server state types.
+export type TodoList = ServerState & typeof todoList;
+
+// Injects the final types when calling the `store` function.
+const { state } = store< TodoList >( 'myTodoPlugin', todoList );
+```
+
+So far, so good. Now let's create our `add-post-to-todo` block.
+
+First, let's add the current post title to the server state.
+
+```php
+ get_the_title(),
+));
+?>
+
+
+```
+
+Now, let's type that server state and add the client store definition.
+
+```ts
+// add-post-to-todo-block/view.ts
+type ServerState = {
+ state: {
+ postTitle: string;
+ };
+};
+
+const addPostToTodo = {
+ actions: {
+ addPostToTodo() {
+ const todo = `Read: ${ state.postTitle }`.trim();
+ if ( ! state.todos.includes( todo ) ) {
+ actions.addTodo( todo );
+ }
+ },
+ },
+};
+
+// Merges the inferred types with the server state types.
+type Store = ServerState & typeof addPostToTodo;
+
+// Injects the final types when calling the `store` function.
+const { state, actions } = store< Store >( 'myTodoPlugin', addPostToTodo );
+```
+
+This works fine in the browser, but TypeScript will complain that, in this block, `state` and `actions` do not include `state.todos` and `actions.addtodo`.
+
+To fix this, we need to import the `TodoList` type from the `todo-list` block and merge it with the other types.
+
+```ts
+import type { TodoList } from '../todo-list-block/view';
+
+// ...
+
+// Merges the inferred types inferred the server state types.
+type Store = TodoList & ServerState & typeof addPostToTodo;
+```
+
+That's it! Now TypeScript will know that `state.todos` and `actions.addTodo` are available in the `add-post-to-todo` block.
+
+This approach allows the `add-post-to-todo` block to interact with the existing todo list while maintaining type safety and adding its own functionality to the shared store.
+
+If you need to use the `add-post-to-todo` types in the `todo-list` block, you simply have to export its types and import them in the other `view.ts` file.
+
+Finally, if you prefer to define all types manually instead of inferring them, you can define them in a separate file and import that definition into each of your store parts. Here's how you could do that for our todo list example:
+
+```ts
+// types.ts
+interface Store {
+ state: {
+ todos: string[];
+ filter: 'all' | 'completed';
+ filtered: string[];
+ postTitle: string;
+ };
+ actions: {
+ addTodo( todo: string ): void;
+ addPostToTodo(): void;
+ };
+}
+
+export default Store;
+```
+
+```ts
+// todo-list-block/view.ts
+import type Store from '../types';
+
+const { state } = store< Store >( 'myTodoPlugin', {
+ // Everything is correctly typed here
+} );
+```
+
+```ts
+// add-post-to-todo-block/view.ts
+import type Store from '../types';
+
+const { state, actions } = store< Store >( 'myTodoPlugin', {
+ // Everything is correctly typed here
+} );
+```
+
+This approach allows you to have full control over your types and ensures consistency across all parts of your store. It's particularly useful when you have a complex store structure or when you want to enforce a specific interface across multiple blocks or components.
+
+## Importing and exporting typed stores
+
+In the Interactivity API, stores from other namespaces can be accessed using the `store` function.
+
+Let's go back to our `todo-list` block example, but this time, let's imagine that the `add-post-to-todo` block belongs to a different plugin and therefore will use a different namespace.
+
+```ts
+// Import the store of the `todo-list` block.
+const myTodoPlugin = store( 'myTodoPlugin' );
+
+store( 'myAddPostToTodoPlugin', {
+ actions: {
+ addPostToTodo() {
+ const todo = `Read: ${ state.postTitle }`.trim();
+ if ( ! myTodoPlugin.state.todos.includes( todo ) ) {
+ myTodoPlugin.actions.addTodo( todo );
+ }
+ },
+ },
+} );
+```
+
+This works fine in the browser, but TypeScript will complain that `myTodoPlugin.state` and `myTodoPlugin.actions` are not typed.
+
+To fix that, the `myTodoPlugin` plugin can export the result of calling the `store` function with the correct types, and make that available using a script module.
+
+```ts
+// Export the already typed state and actions.
+export const { state, actions } = store< TodoList >( 'myTodoPlugin', {
+ // ...
+} );
+```
+
+Now, the `add-post-to-todo` block can import the typed store from the `myTodoPlugin` script module, and it not only ensures that the store will be loaded, but that it also contains the correct types.
+
+```ts
+import { store } from '@wordpress/interactivity';
+import {
+ state as todoState,
+ actions as todoActions,
+} from 'my-todo-plugin-module';
+
+store( 'myAddPostToTodoPlugin', {
+ actions: {
+ addPostToTodo() {
+ const todo = `Read: ${ state.postTitle }`.trim();
+ if ( ! todoState.todos.includes( todo ) ) {
+ todoActions.addTodo( todo );
+ }
+ },
+ },
+} );
+```
+
+Remember that you will need to declare the `my-todo-plugin-module` script module as a dependency.
+
+If the other store is optional and you don't want to load it eagerly, a dynamic import can be used instead of a static import.
+
+```ts
+import { store } from '@wordpress/interactivity';
+
+store( 'myAddPostToTodoPlugin', {
+ actions: {
+ *addPostToTodo() {
+ const todoPlugin = yield import( 'my-todo-plugin-module' );
+ const todo = `Read: ${ state.postTitle }`.trim();
+ if ( ! todoPlugin.state.todos.includes( todo ) ) {
+ todoPlugin.actions.addTodo( todo );
+ }
+ },
+ },
+} );
+```
+
+## Conclusion
+
+In this guide, we explored different approaches to typing the Interactivity API stores, from inferring types automatically to manually defining them. We also covered how to handle server-initialized state, local context, and derived state, as well as how to type asynchronous actions.
+
+Remember that the choice between inferring types and manually defining them depends on your specific needs and the complexity of your store. Whichever approach you choose, TypeScript will help you build better and more reliable interactive blocks.
diff --git a/docs/reference-guides/interactivity-api/iapi-about.md b/docs/reference-guides/interactivity-api/iapi-about.md
index 887a284be298fb..08689be03aa383 100644
--- a/docs/reference-guides/interactivity-api/iapi-about.md
+++ b/docs/reference-guides/interactivity-api/iapi-about.md
@@ -130,7 +130,7 @@ store( 'wpmovies', {
>