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?
Related
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?
I working on a project that need to upgrade redux-form to react-final-form. I just wonder that is there any documentation for that task.
EDIT: 🎉🎉🎉 There is now a Migration Guide!! 🎉🎉🎉
I meant to make a migration guide, but it's just so easy that I never found the motivation to do it. But I'll write a little here for all of the people who find this excellent SEO-bait via Google.
Rather than "decorate" your form component with a HOC, you use 🏁 React Final Form's <Form> component inside your form component to give you all of your form state via a render prop. Most of the config stuff from Redux Form maps directly onto props to <Form>, e.g. initialValues, onSubmit, etc.
The <Field> API is nearly identical, but with the added benefit that you can define how your field is rendered inline via a render prop (using a "fat arrow" function as your component prop in Redux Form was forbidden and a common pitfall). 🏁 React Final Form has a few extra bits of field state, like dirtySinceLastSubmit, which can come in handy.
By default, Redux Form would not rerender your entire form on every value change, forcing you to use a getFormValues() selector if you needed them in realtime. React Final Form does rerender on every value change by default because for most small forms, this is just fine. But 🏁 React Final Form allows fine tuning of rerendering via providing a subscription prop to <Form>, specifying exactly which pieces (slices) of form state you want to rerender for. Then, any time you were using a selector in Redux Form, you would use a <FormSpy> component in 🏁 React Final Form, which allows you to subscribe ("select") parts of the form state to rerender for.
As linked in the other answer, this talk explains the difference pretty well. More talks will be given later in 2019.
I know It may sound like a dumb question, But I am not able to get this solved in my head. Please bear with me.
In case when we use a state management system in React like Redux / Mob X, I guess the main purpose of these state management techniques is to provide a single source of Data and a more structured approach of updating it.
Say, I am Using a state management library(MobX) for React, And suppose I have a parent component which makes an http API call and updates the MobX store with the API response. Now I need that data in one of child/nested components.
My Question is, Should I pass that data as a prop to child component or should I enable child component to connect with Central Store and directly get that data ?
by connecting the child to store, I am turning the Child into a class component, which is making it more heavy and React optimisations may not apply. I am defeating the whole purpose of a functional component.
Awaiting replies.
Best Regards,
Lalit
This completely depends on the situation. I would suggest splitting your components up in 2 parts:
Components that could be re-used in other projects
(Higher level) Components that are so specific to this project that they probably never will be re-used.
For components of category 1, I would suggest not using mobx store directly, but instead make pure react components. (eg think of a dropdown, or an ajax dropdown component).
For second part components (think of, header, footer, section components specific for your website). just make them directly interact with the Mobx store, so that you can way quicker code what you need (instead of constantly having to prop everything).
addition
For components of category 1 you can always wrap them with the #inject() method. This way for example you could turn a dropdown component into a UserDropdown component that uses the mobx store for its state. (The inject method injects mobx state as props in the component).
const UserDropDownComponent = mobx.inject(stores => ({users: stores.userStore.users}))(DropDownComponent);
// usage:
<UserDropDownComponent />
Warning
For pure components wont always see changes of mobx state. To Fix this you need to wrap the component in an #observe annotation. Or you have to inject the props by wrapping it into: mobx.toJS(yourMobxStateProperty)
I've converted most of my containers to functional components to make them reusable and I'm wondering if it's good practice to pass Action Creators as props to theses functional components.
In this case, I'm using a tab to switch between Login and Sign Up page and I'm using local state to manage active class (for styling). I call action creators passed down as props to switch between rendering a login or sign up page. I'm using this tab in several places and I'm passing a different configuration object as per use cases.
homePageTabProps = {
firstTabTitle:"blog",
secondTabTitle:"resume",
showFirstTab: this.props.showBlogTab,
showSecondTab: this.props.showResumeTab
}
Is this good practice? yay or nay?
Edit:
The active tab style is giving me problems (retains value when reusing the component). Can I have local & global state? (Sorry if this sounds stupid.)
Passing functions as a props down the hierarchy of your Components is for sure widely accepted practice. But I would suggest not to pass bare action creators, but bind them to dispatch before passing them to Component. This way, if your child Component is not connected to store it will not have to know about Redux at all (no need to manually dispatch).
As for your complication with two states. There is nothing wrong in mixing own Component's state with part of Redux passed to Component via connect. I would even strongly recommend to keep all temporary data not important to your application logic inside Component's state without exposing it to Redux. For example, most of the time, there is no sense in sending animation timings, intermediate state of user input, etc. to Redux.
But, in your case looks like indication of active tab is a direct reflection of Redux state and should be fetched from store. Otherwise it's not clear why you are sending actions to Redux on tab's change.
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.