In short we are going to be doing two things here:
#Redux reducer how to#
However, because this is just a work sample, and because replacing the list is the simpler operation of the two options, we are going to go through the process of merging the list, so that we know how to do that for future reference. In the case of this application, in the real world we would want to replace the entire list of streams, so that if another user shut down their stream, we would not still be able to see it, as it would have been removed from the canonical source list. However if we were treating the server like the canonical source of truth for the list of servers we would to replace our current store. For example, if we were doing something like creating an infinite scroll list, we would want to merge the results from the server with our current list and append them to the end. The second thing that we need to consider is whether or not we want to completely overwrite the whole list of streams with the response from the API server, or whether we want to merge the streams from the API with our current list in the store. So we are going to have to convert from an array of objects to an object… of objects. An object that contains lots of other objects. The first thing to understand is that our API server is holding the streams in an array, and our store is holding all of them in an object. There are some things to discuss here before we get into this.
The last reducer that we need to take care of is to fetch the list of streams. Import = state return newState default : return stateĪnd the one part here that might be confusing is that we did not use payload.id because in our action we ONLY sent the ID in the payload, so we do not have to specify a property of the payload. So understanding the object manipulation methods above and that we are going to be using the stream ID as the key:value pair, we can go ahead and scaffold out the streams reducer and create our first case for editing a stream like so.
Scaffolding the Streams Reducer Reducing Single Records We never send back the original array/object to the store, it must always be replaced with a new one. Remember that the goal is to create a new copy of the original data, and manipulate it in some way. Just as a refresher, here is our list of strategies to manipulate arrays and objects in reducers. Naturally we will use the stream ID as the key:value pair for these objects. Now we are going to use reducers to return objects, and use key value pairs to target specific streams inside of those objects. We have previously discussed array based reducers here: Ncoughlin: Intro to Redux #reducers We have created actions for our CRUD operations, and now must create reducers for those actions. We are in the process of creating CRUD operations for video streams using an external API server and Redux.
#Redux reducer series#
I came across on post in the mighty stackoverflow by Dan Abramov where he was explaining how to apply this technique and how Twitter was using it at scale.īingo, now I just needed to implement it for my own use case.This post continues our series creating a Twitch Clone called “Glitch”. But how is possible to name or instantiate a reducer without knowing how many tabs or pages you will have? Remember everything is dynamic, one tab per user, one page per album (or whatever type of data you have).Īfter a lot of research I discovered that it was possible to lazy load and create reducers functions on the fly. The ideal solution to take in this case, is to use a separate reducer for each page or tab so that conflicts and race conditions are not anymore a concern. However these sets of problems were becoming unsustainable to manage and a real nightmare to scale, therefore I decided I had to drastically change my approach to the problem. Let’s say we are accessing one tab and then decide to switch to another tab while the first request is already started when we reached the other tab a second request will be triggered and the reducer will receive two sets of data subsequently one way to avoid this was to leverage the cancel effect provided by Redux-saga. To make the matter worse I had to deal with pagination and race conditions. My problem was having multiple dynamic pages and tabs depending on the same reducer, this meant that the state needed to be reset every time the screen was changing, this was drastically increasing unnecessary API calls. Unfortunately when dealing with big applications, the common Redux patters start to break. Yes, there is a substantial amount of boiler plate to manage, also counting that you are always likely to add additional middlewares, but I personally do not mind. I think Redux is still one of the best tool for managing state in large application.
0 kommentar(er)
