5/31/2023 0 Comments Redux middlewareThe first reaction to this idea, from a crafty JavaScripter like yourself, might be to overwrite store.dispatch with another function that does some logging and then calls the "real" dispatch. ![]() Plus, since we know that all changes to state result in a new copy of the state, we could even console.log the whole state object after each action to know what it contained at that particular point in time. You can even persist and "replay" things that happened.īut, to build anything that does that type of thing, we'd need a way to "tap into" what's happening in Redux to observe which actions are dispatched. Since the state is a simple object with a set of actions applied in order (which are also simple objects), it's relatively easy to observe what's happening in your app. If you think about it, since we have a starting state and a bunch of action objects dispatched to store, we should be able to repeat the same steps to end up in the same state! That's the "predictable state container" part. But if that's all we did, we'd miss out on a lot of the cool benefits we can get from having a "predictable state container" with simple serializable actions, etc. Cool, so that means we're done, right?! Let's all go home □. So far we have a clean, structured approach to storing application state, making updates to it, and getting notified when it has changed. Without a structured approach for dealing with state, you're likely to code yourself into a corner. If, by contrast, you're building Twitter Lite, the official mobile web app for Twitter, there's a lot more state to manage. But rarely do we build things that are so simple. In fact, there wouldn't be much use for Redux at all. If all you had to ever build with Redux were ToDo applications with local, synchronous state changes, you really wouldn't need much more than what we've already talked about in previous chapters. In this scenario, our middleware merely says "I don't care about what this action is I want to send it through to the next middlewares to decide about whether it should reach the store.dispatch or not".Middleware, Store Enhancers, and other fancy words! So the result would be like when this middleware didn't exist at all. In the second return, our middleware calls the next function, which as I described before, is the next middleware in the row, and our middleware sends the original action to it without changing anything. This statement breaks the chain of the middlewares, before the action reaches the store, and starts a new dispatch with a new action. So the action that has been passed to our middleware initially, will get completely forgotten. ![]() ![]() In both of them, our middleware says that it has finished its job with this action and lets the dispatch chain continue But in the first return statement, the middleware calls the original dispatch directly and passes a new action with a new type to the dispatch. ![]() RootReducer, // this is defined elsewhere and effectively handles actionsĪpplyMiddleware(forbiddenWordsMiddleware)
0 Comments
Leave a Reply. |