My app have got a lot of dynamic inputs which you can increment, remove and edit, problem is that before kill app I have to store current form state, values cannot be cleared.
Mapping values inside func component from a redux state slows down rendering because every render, refs are created again and current ref always equals null, using useRef with createRefs inside creates new issue because newly created inputs doesn't invoke newest references and rendering last input throws error.
Right now values are stored with redux persist, refs are stored in separated reducer named formRefs which is in blacklist in redux-persist.
I don't know if this may aggravate performance of redux. everything works but redux is overloaded when I'm opening redux devtools and it's crashing. Any one got similar issue? Any better solutions?
Related
I have global state working via Context/AppState/AppStateDispatch. I also have component state working via useState.
But there are times when it appears it might be helpful to avoid using these:
We need immediate access to the value in the current function and can't wait for the next render to get it. Storing it via useState/AppStateDispatch would prevent the value from being accessible until the next render
...and, those same values are needed globally throughout the app
...and a useRef would be destroyed on component unmount
In that case, it seems like it might be appropriate to use a globally-available, non-render-causing object to hold state for these items.
It's pretty easy to implement... but it seems non-React-y. Am I missing something?
I looked into this pretty extensively the past few days. Here are a few observations.
In my use case, I'm using an external webRTC service. Their code requires my app to install listeners for incoming calls, responses to publication of video streams, etc. The listers needs to access the component's webRTC-specific variables
At the same time, those variables can't be part of component state or app state, because when updated, their values won't be available until the next refresh, and the rest of the component needs to access them within the current render.
Using an application global var that is apart from React and doesn't trigger a refresh is, of course, kludgy.
Here's the approach I'm using at the moment. So far it appears to be helpful.
Create an application-state object to store all variables related to my component's use of webRTC.
Initialize it via a call to a function, getWebRTCDefaults().
On component mount, copy it from app state to a component-level variable. Note-- it is not in component state -- it's a component-level variable, accessible anywhere in the component.
As such it can be updated anytime within the component and its values are immediately available throughout the component.
When a call starts and ends -- and only then -- I use React context dispatch to update the app state object. I.e. I do not update that object via useEffect as that could cause unnecessary renders.
This approach seems to be helpful. I can unmount the component and when I remount it, it picks up where it left off -- the webRTC video is still running.
In my React app, I have a redux reducer which sends a List as props to my component.
I copy the prop to local state, and show as drop down. User changes the Dropdown so my local state changes.
On click of cancel , I am calling redux Toastr which triggers a method to reset my state with the original props.list. But for some reason the props.list also changed similar to my state change. With my knowledge i thought props passed to the componeent will not be changed until again i call action creator.
Anyone faced similar issue? or i am doing something wrong
Sorry for not posting the code, which I will prepare a demo if needed. Thanks!
What you are doing is an anti-pattern as you are breaking react's rule of single source of truth. You can't hold state internally in a component that is tied up with your redux state and expect it work smoothly. A similar issue of breaking the single source of truth arise when using solely React without Redux and when you try to pass props as state. In this case there is a new lifecycle hook static getDerivedStateFromProps but even this hook is advised to be used sparsely you can read about it here. So if your intent is to reset state back to it's original value, you can either:
Use static getDerivedStateFromProps (which is reserved mostly for UI)
Use a key prop which will reset you back to your initial state
Use a memoization helper such as memoize-one
I am new on react. I am working on react application with redux. I have a form (I am using redux-form) by which I can save data or edit data.
my problem is , In edit mode I populate data using componentWillReceiveProps. and populated perfectly, now when I try to clear any field on form its again fill.
componentWillReceiveProps(nextProps){
this.props.dispatch(initialize('NewProject', nextProps.project.project[0]));
}
I would be grateful for any help.
Is there a reason you're not dispatching this action somewhere else, like in componentDidMount? I can't say without seeing more code, but it's possible that whenever you edit your form, React again calls componentWillReceiveProps and overwrites whatever you did with the behavior you've given your component.
Per the React documentation:
Note that React may call this method even if the props have not changed, so make sure to compare the current and next values if you only want to handle changes. This may occur when the parent component causes your component to re-render.
It may be a good idea for you to move your dispatch to a more predictable event if possible, like componentDidMount. Typically, your render method should be capable of handling different cases if a component has multiple possible states. You could also create an edit and save version of your component, and render one or the other based on the props you receive. The best way to "populate" data, as you put it, is to define propTypes for your component, and then use your props to insert that data into elements in the render method.
I'm not sure it is default behaviour or redux or something else but i found that on dispatching an action, this action traverse through all reducers(that's ok) but it also invoke the connect listener of every reducer that further resulting rendering of its component. This means on every dispatch, all component inside app state tree get rendered. Is this intentionally done by redux or i've done something wronge.
Help me out to clarify this things.
In Redux , your state is global and handled by the redux, whenever you dispatch an action , you are just setting the global state. Your container comonents will receive the new state and reducer would work on them but your components wont be rerendered since previous state and next state would be same.
Only those components would be rendered whose mapStatetoProps result in a different result
This behavior is totally fine. See the React Docs for their virtual DOM concept:
React makes use of a virtual DOM, which is a descriptor of a DOM subtree rendered in the browser. This parallel representation allows React to avoid creating DOM nodes and accessing existing ones, which is slower than operations on JavaScript objects. When a component's props or state change, React decides whether an actual DOM update is necessary by constructing a new virtual DOM and comparing it to the old one. Only in the case they are not equal, will React reconcile the DOM, applying as few mutations as possible.
So you don't have to worry that every component will get re-rendered every time you dispatch an action.
So,
I just spent 2, gulling, days getting a tcomb-form to work with my React component, keeping options, values and the type in Redux and building part of the form after an ajax call to an API get its data.
It only now occurs to me to ask if anyone has done a reusable tcomb-forms-Redux-React component that i can do all this in so one would just inherit said component, define the type, where in redux you want to keep the state and then poof it just works.
Anyone?