Tell us what’s happening:
I just want to make sure what i studied is something like this. Please someone reply on this.(also the flow of diagram)
Your code so far
Your browser information:
User Agent is: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36.
Challenge: Extract Local State into Redux
Link to the challenge:
Yeah, that looks basically right. But yeah, this is kind of confusing until you’ve used it a bunch. Did you have a specific question?
The only comment I would have is that you should use the object shorthand form for mapStateToProps. MDTP is almost always taught as a function, but the redux docs recommend using the object form (even though the inexplicably start with and explanation of the function form.) I haven’t used the function form in years. The only time I see it is in legacy code or new developers that don’t know any better. If you build your action creators correctly, there’s no need for the function form.
I now see that the challenge to which you linked uses the function form of MDTP [sigh], so, go ahead and use that, but look into the object form - it’s a lot easier.
The only advantage I see to teaching MDTP as an object is that it kind of explains what is happening behind the scenes. The problem is that some people never move on from that.
I have a specific question, the MDTP used "message " as an argument. onClick collect the input to action creator through MDTP. And in the MSTP we use “messages” for returning the data inside the state array?
It is unclear to me whether you have successfully completed this challenge and are asking how it works or if you are struggling with it and need help. Let me go through the flow of the challenge when it is done properly.
Does that help? Or does it make it worse?
One comment, I think that redux made a mistake when they used the word “state”. I wish they had stuck with the word “store” to avoid confusion with the React use of the word “state” - there was already enough confusion.
If you are in fact still having difficulties with the challenge, then please paste your code so we can have a look.
Thanks for that help. so we always need a local state to store the data first, then we use MDTP to access that data and process through action creator. Is there any way to avoid all local state?
I got this challenge. However just making sure about what i have learned.
so we always need a local state to store the data first
No, I wouldn’t say that. In this case, that makes the most sense because we want a controlled input. I would say that in my coding when using redux, I probably use local state less that 5% of the time, just when I need it. (But that percentage could vary widely depending on the type of app.)
… Is there any way to avoid all local state?
Sure, we could store that in the redux store, too. I don’t think that’s the best idea, but it would work just fine, if we created the action creators and reducer we needed.
This was actually and interview question I had to answer the day before yesterday. (I must had done well - I got a job offer.) “When using redux, when would you want to use something on local (component) state?” I think things that only the component needs to know about. Does the entire app need to know about the input that is local to only this one component? Almost certainly not. On the other hand, does anywhere in the rest of the app need to know about the messages array? That’s hard to say without seeing the rest of the app, but that is a realistic possibility, especially since if I was building this app, I would have had the input in a different component than the output - things would get a little messy without redux - doable but messy. Also, we probably want that messages array to persist even if this component unmounts (e.g., from navigating to another part of the app).
I think my answer to the interview was something along the lines of “If it’s something the rest of the app needs to know about or that needs to be persisted, then it should be in redux. If it is about the internal business of that component, it should be in component state.”
then we use MDTP to access that data and process through action creator.
I’m not sure I understand that statement. I think this would have been clearer if this app had been split into two components - one called Input that uses MDTP and once called List that uses MSTP.
MDPT takes in our action creators and creates a function that will dispatch an action object that will be created by the action creator. This gets placed on the component props by the HOC returned by connect so that it is available within the component.
MSTP will just read things off the redux store and map them to an object that will get merged with the component props, using the same HOC returned by connect.
When you submit, your dispatching function (submitNewMessage, provided to the component by MDTP and connect) will set off a chain of events that will cause the reducer to update the redux store. This will cause MSTP to fire that will provide the updated props to your component which will trigger a rerender.
Yep, but in the MDTP we use a dispatch(addMessage(message)) to get the input data. How can i avoid using that line, so that i can transfer the input directly to the Redux store
I’m not sure I understand, but I think you’re looking for this, the object shorthand form of MDTP I mentioned above.
connect can take a function or an object. You have been taught the function form. The function form is a little more powerful, but it is a lot messier. I’ve never needed it in my own code. I would have used the object form:
const mapDispatchToProps = {
submitNewMessage: addMessage,
};
Here we just give connect an object and it knows what to do. It knows to take the action creator addMessage, wire it up with dispatch and pass through any parameters that get passed to our dispatching function. That’s basically what you’re doing with your version, but since this is soooooo standard, connect lets you just pass an object and it can figure it out.
You will still need to pass the local state message into your dispatching function in submitMessage because there is no way for the global redux store to know what is happening in the local component state.
Could it be made to work that way? I guess. If you stored the input data (that is now in local state) in the redux store and have the same reducer handling that and the message array. Sure, that could work, but I think it would be a baaaaaaaad idea. Your reducer would be trying to handle two things. In the real world, you will have several reducers, each having its own area of the redux store that it manages. (This technique will be covered later.) And it’s a bad idea because now your component doesn’t have control over its own input or what data is dispatched. What if you wanted some validation or normalization on this data? Are you going to put that in the reducer? Then you’d need that logic in multiple reducers if you wanted to reuse that input. And it is a bad idea because, as I said before, you would be polluting the redux store with something that only one tiny component cares about.
Is it doable? Sure. Is it a good idea? No.
I think the example given by the FCC challenge is a good pattern, ignoring my quibble about using the function form of MDTP.
Thanks for that Kevin Smith
Yeah, like I said, redux is weird. It’s such a different way of thinking. At first it seems overly complex, but as you get used to it, you realize its beauty and power.