In my application I have a dialog window on which there are multiple input fields. What I want to do is to save user's input in the component's own state and only afterwards, say, inside "onClose" of the Dialog send the input to a redux store using "dispatch" function.
This way the dialog component would keep field data inside its own state.
The problem that I face is that I'm not sure what the best way is to rebuild dialog component state from information contained in the redux store.
If one refreshes the page with F5 or simply reloads it, then components lose their state and fields will appear blank, regardless of the fact that rehydrated redux store still contains valid input information.
The question is then, what is the best way to set components state from props? Moreover, doesn't it seem like an antipattern? What are some common techniques for such task?
One possibility is to set field values directly to those contained in "props". This would, however, imply that every small change of the input fields will result in copying and modifying redux store, which is slow & inefficient.
Usually building a state from props complicates code a lot, you have to map props both in constructor and getDerivedStatesFromProps.
I prefer to write component functions which return value based on passed props.
As you mentioned it may impact perfomance, to fix it you can use memoize-one library.
For more details you can check the following answer
Related
I have a sequential data collection app built with React and Redux. Right now, I have internal state for each page which has a form and when user clicks "Submit" button, I am dispatching the data collected in the state and updating my Redux store. Should I be dispatching an action on every key entered(debouncing) or should I store it in a local state and update Redux store at once?
Will there be a performance issue if I dispatch action to Redux store on every keypress since it is not an asynchronous call.
Well, the answer is: it depends.
Some argue that we loose some of the advantages of using a central store (like Redux) if you also have an internal state in the components. Like, if all your application state is just the redux store, storing the store, or the sequence of actions that lead to that store, will give you a complete picture of what was happening before maybe an error occurs.
I believe that is excessive. It is completely fine to store little stuff in your component's internal state, but there should be a well defined line.
In case of a form, you'd have controlled input elements, and you'll want a mechanism to submit the form with an action. It'd be necessary to have the contents of the form in the redux store.
One way would be to have the contents in an internal state, and only put them into redux form after a little debounce. But that has some edge cases. What if the user submits the form in the little debounce time? The form in the store is incomplete. Is thinking about all the edge cases worth it?
I believe just having the form elements controlled from the redux form is the simplest solution. The performance issue one would imagine is not really an issue. This is also what redux-form does (you can look at how that is implemented for inspiration).
Typically, when I've created a form in react/redux myself, I have managed the inputs as 'controlled components', meaning when an input box changes, it calls a function that updates a variable that is fed back into the input. Of course, for me, this is the crux of redux, it's the flow.
However with redux-form, it seems I have no ability to do this on each of the fields. Almost as if, the fields are controlled, but within redux-form's own world, as far as I'm concerned they're not controlled as I'm not passing a value and re-acting to a change with a callback.
This is causing me a problem, as I may have something else that updates those input fields. For example a postcode lookup might update an address's fields. Before I transitioned to redux-form, the 'flow binding' meant I could update those fields from a different reducer as they essentially just represented a live slice of the redux store.
How do I get around this?
Edit: I think the best approach might be to use this https://redux-form.com/7.0.3/examples/selectingFormValues/, but I'm not sure
Field values of redux forms can be modified using the reducer plugin. Basically you can add your own reducer to the one of redux form anf modify forms state like values, touched etc. Check it out here:
http://redux-form.com/7.0.3/docs/api/ReducerPlugin.md/
Be aware is an advanced usage of redux and redux forms.
There are many answers regarding react component communication, but seems none of them resolved my problem. Here is my problem's detail. Please help! Thanks in advance.
I'm building a flexible form. The UI is generated by nesting components.
The form data structure could also be nested json objects.
i.e form can have some inputs and sections, sections can have some inputs or sections, and go on.
sections is just UI layout components, doesn't care about data or state.
But input (could be text input, checkbox etc anything to capture data)
The problem I'm facing is any input's validation could depends on any other inputs' value.
i.e inputA has validation expression like formData.inputB >formData.inputA + formData.inputC
But they could also have no dependency at all if you don't give a validation expression.
If I pass the whole formData down the component tree, every time I type in one input, the whole form will rerender.
I have considered redux, but real not sure how redux can help such case. I'm still relative new to react and redux, so I could be wrong.
So what could be a viable solution?
Its a common issue when you're modularizing form elements. I have the same problem.
Redux is by far the most controlled solution. All of the components can listen and update the same object simultaneously. But you can also attach functions as props from the parent that you bind to the parent. The function would fetch the state of the parent and update the state like a makeshift store. If you're a good developer, this is possible but neither are simple to do. Good time to learn :)
There are various solutions to your problem, but in general it shouldn't even be a problem, because rendering (even of large forms) should be quite effective with React.
The core tool for adjusting performance in React is the shouldComponentUpdate method of your component classes. If you're smart about what you pass to the individual form fields and then implement shouldComponentUpdate properly on them, you should be able to update only when needed. In your particular example, you don't need to pass the full object everywhere.
You can just pass value, onChange and isInvalid to each field and calculate the validity at the root (where you have access to the full state). Then the shouldComponentUpdate of your fields can decide just based on those props. (Obviously this is a simplistic example, but as a principle it's sound.)
Sure, Redux is another possible solution. If you keep the state in Redux store and only connect each of your fields to the portion of the state it needs, you should be all set. It brings quite a change in architecture though, so you should choose Redux only if you really want it for your app as a whole.
I have two components, contact form, and input.
At this moment i pass onChangeEvent from contact to input as is described in many tutorials and its works fine - input update his owner state.
But there is way to pass 'this' from contact to input by prop, or context and then I can update owner state without passing onChangeEvent - but is this a good idea?
Is there another option to update owner state without passing onChangeEvent?
I believe you could technically do it, as a React component is a regular javascript object in the end, so you could pass it as a prop.
However, that's not a good idea in general, for various reasons:
It tightly couples the two components together. If you ever want to reuse the input component in another place, you'll need to pass in the exact same state.
Linked to this, it allows manipulation of the internal state of one component, by another component, which is a violation of good OO design.
You are right however, that things tend to become quite verbose when working like this. They also become hard to reason about when one has more complex trees of components passing props and change handlers between them.
One solution to the problem, is employing the Flux design pattern, and namely it's Redux implementation.
In Redux one has a single piece of global state, a plain object, of which components see pieces (sub objects). Components receive this state as props, and just render from it in a simple fashion. There's a set of actions which transform this state, and any component can issue such an action, as a result of user interaction. There's still the concept of "state", but it is reserved for truly local things, such as the state of a form before pressing the save button etc.
Suppose a complex component is subscribed to the redux store. The first time the component is mounted, we aggregate a lot of data from the store and create a "ModelView" object.
Then, imagine that this component receive an event to update itself because there's a new state. It seems like the render method would need to re-aggregate all the data from the store to know if there's a difference. I.e. we cannot do a simple comparison because the ModelView object is different than what's in the store.
You may ask "Why a ModelView", why not just read data from the store in render(). This is a fine approach for simple pages, but for complex pages the lag is noticeable and it is just not possible.
Also, a view may have an internal state that is different from the store. For instance, maybe a few tasks have been updated in the store, but we don't want to change the UI because that would be confusing for the user.. we'd rather show a "Click to see new change" button for instance. One approach to that is to store everything in the store.. both the ModelView AND the normal state.. but isn't that overkill? Or said differently, shouldn't the ModelView be stored inside the component itself?
Computing Derived Data is a recipe describing how a memoized “view model” can be derived in a composable way from the Redux store thanks with Reselect.