Now we've created an implementation that is a bit more specific to our needs, with a helper function we can use when we create actions. We might expand on this later to provide a separate helper for server updates, but for now this is all we need.
Now we've created an implementation that is a bit more specific to our needs, with a helper function we can use when we create actions. We might expand on this later to provide a separate helper for server updates, but for now this is all we need.
You don't actually need to create an AppDispatcher in every application, but we wanted to show it here as an example.
You don't actually need to create an AppDispatcher in every application, but we wanted to show it here as an example. The creation of the AppDispatcher allows us to extend the functionality of the Dispatcher. In this application, for example, we have provided metadata about the source of the action outside of the action itself.
Creating Stores
Creating Stores
@ -661,7 +661,7 @@ waitFor(ids) {
}
}
```
```
Now within the store's callback we can explicitly wait for any dependencies to first update before moving forward. However, if Store A waits for Store B, and B waits for A, then a circular dependency will occur. To help prevent this situation, the dispatcher will throw an error in the brwoser console if we accidentally have two stores that are waiting for each other.
Now within the store's callback we can explicitly wait for any dependencies to first update before moving forward. However, if Store A waits for Store B, and B waits for A, then a circular dependency will occur. To help prevent this situation, the dispatcher will throw an error in the browser console if we accidentally have two stores that are waiting for each other.