I am new to React. I have a small app I'm designing with a schedule and with list of products. Please see my component diagram, below.
I propose that The Schedule Controller and Product Control each will be a class with state.
I brought all the Product modules (a listing component and its children, A new product form, a product detail module, and an edit product module) to be direct children of the Product Controller to prevent excess prop drilling, so they can all pull from the product control class state.
So, as I'm thinking about this, I'm mindful of a single source of truth and to concentrate a single state. However, I've always done that because the whole app has one class.
It seems to me that, to obey those laws (and without using a store as in Redux, which I'm not ready to work my way up to yet. This is a learning exercise and I want to get some proficiency with regular React before adding a whole new library to my learning) I should pick the highest parent component and make only one class with one state.
It seems to me that when I use setState(), its going to the use the state of the class it inherits from. Right? And that state isn't going to get confused about which state to use, because its going to the parent class (I'm totally out on a limb here). The product modules will be extended from the Product class and setState() will only go up the chain to the parent and the parent state.
Or is the correct approach to squash the schedule modules as children of the product controller?
I did a lot of looking around and the references I keep finding are much more complex than what I'm attempting here (involving two different classes with state that DO share information, that's not happening here). I may not be searching the correct terms. So I'm sorry if this is something well known.
So the question I have is, is this a bad idea or bad practice?
A setState call in a class Component only sets the state of itself.
There are two forms of class state
State-> This will be the local state of the class. It will be changed and maintained by the class which declares it.
Props-> These are states/properties which are passed from the parent to the child class. This value cannot the changed. Only the parent class which owns these props has the power to change it. The only way to change this would be through lifting the state. You are right here.
Refer https://reactjs.org/docs/lifting-state-up.html
marzelin had the answer in the comments above. Thanks!
Related
The bounty expires in 6 days. Answers to this question are eligible for a +200 reputation bounty.
Jeff is looking for a canonical answer:
the bounty will go to the answer that provides a detailed component design, describing the components and hooks needed to implement this. It would be nice to reference a sandbox or actual code, but not necessary.
I have a faceted search component that I am building. I am having trouble figuring out how and where to handle state.
Solution #1
A parent component manages state - uses a reducer to manage all components and pass state down
Cons: child components have a lot of complexity (autocomplete, focus state) and updating the state at the parent level causes child components to re-render. This means the child component's focus state and suggestions do not work well.
Pros: Somewhat cleaner design, state handled in one reducer
Solution #2
Child components manage their own state (like uncontrolled components). Parent component just manages creating, deleting new complex components. Children update a ref on the parent once they know they are completed (lose focus).
Cons: managing two pieces of state and duplicate key bugs
Pros: child components work as expected
Help and Suggestions
Both solutions are difficult to implement, but so far I am having better luck with solution #2.
Are there any good examples of this out there? It seems that editable todo lists would have a similar issues.
I like the idea of solution #1 but I think I would need a way to defer updating the state.
When your state is complex and used by multiple siblings/children, you definitely want that state to live on the common parent. Solution 2, where siblings each manage part of a complex state will become a nightmare to maintain - as you'd have to keep all those different states in mind while working one one.
Another thing to keep in mind is the shape of the state itself. For a state consisting of multiple types, useReducer() is going to be your better option.
For example; a complex state is :
... = usestate({
"user" : {
"name": "",
"age" : null},
skills: [],
rate: 50,
company: "default",
reviews: [],
});
To update this state, you'll have to write a lot of type checks and different types of spreads. Some are arrays, some int, some String, etc.
At that point, a reducer makes a lot more sense. A reducer handles the state by means of an action and a payload. The state logic then lives in a separate file for these components.
I think this is the way to go: https://www.aleksandrhovhannisyan.com/blog/managing-complex-state-react-usereducer/
I am building a React application and I feel like I have a beginner question, but I can't seem to figure out an answer to it.
Basically, I am building a comparator for credit cards/savings accounts/etc. The pages are the same: I have an header, some filters, a sorting selection and finally "rows" to compare the result. I built this once but I need it 3 times. In this component, there are methods that I will reuse such as the call to get the financial institutions and I can reuse the call to get the differents options. However, I don't want to duplicate my code.
This brought me two options: I can either get these functions, put them in another file and import them or I can make other components inherit from one parent component.
The first option is great, but my methods change the state. If it is external to the component, it won't change the state. (and I don't want to do like var = x() for each call).
The second option would be perfect in other circumstances, but I heard that inheriting in React is bad. However, I feel like this is the only way I can reuse the methods to change the state.
Can you help me figure this out?
(I can give code since I am building this for a company and I can't reveal the code to everyone)
In our experience, thinking about how the UI should look at any given moment, rather than how to change it over time, eliminates a whole class of bugs.
From React Docs
From my understanding, this means that React only updates what's necessary, rather than destroying and re-constructing the entire DOM tree again. Am I wrong?
Can anyone please help me understand the quoted statement?
Thanks.
From my understanding, this means that React only updates what's necessary, rather than destroying and re-constructing the entire DOM tree again. Am I wrong?
If you want to know the short answer, I have to say it is true, React will update the necessary elements in DOM whenever it needed.
But if you want to know how it's done, and when React will update the DOM and its element I have to it is varying to different several things, like project architecture, using proper methods (proper hooks in functional component eg. useCallback, useMemo, and so on) and so on.
When it truly gets rerender then?
As far as I know, there are two ways React finds out when to rerender the DOM.
Passing elements to ReactDOM.render
Update a state
What is ReactDOM.render?
This will call the render() method from react-dom (Where we usually import it as ReactDOM) and it will render a React element into the DOM in the supplied container and return a reference to the component (or returns null for stateless components). Also if the React element was previously rendered into the container, this will perform an update on it and only mutate the DOM as necessary to reflect the latest React element.
What does state mean?
The state object is where you store property values that belong to the component. So when you got a component and that component has their own specific variables where changing them should affect the DOM you should use it, then whenever state gets changes the component will be updated.
So what I even talk about project architecture and this stuff, when I didn't mention anything about it above?
Let's say we got a project with one parent component and 3 child component just like this:
Component 1
- |- Component 2
- - |- Component 3
- - - |- Component 4
So whenever you a state in Component 4 all of the DOM elements will be get rerendered, why then? Because Component 4 is a child of Component 3 and so on, so when the child state gets change it will force the parent to rerender then the whole DOM will rerender once per state change.
Final Note
So, at last, we should be always considered a good architecture and hierarchy for our project or when it necessarily use built-in methods like useMemo to avoid such a thing.
lHello everyone, here is the problem.
We have a grid component with some filtering enabled. When the filtering is applied, if a certain callback-prop exists, it is called with the filtered data as an argument.
The problem is this. If said datagrid is wrapped by a parent component and the parent component saves the filtered data in it's state, it causes the parent to rerender, but also the datagrid. However, when the datagrid renders it runs it's filtering logic, which causes the callback(which is setState() call) to run.
So, to avoid the loop I introduced a variable to the parent component class and save the data there, but it doesn't seem so good to me.
Another option would be redux, just add a new action and dispatch it when the filtering runs.
Any other ideas?
Since you're also asking for other ideas, may I suggest React hooks. They allow finer-grained control, such as multiple states, reducers, memoized callbacks, effects that are only called when inputs change, etc.
How would be perfect to organize data and interaction between two vuejs components? For example:
1) i have one component
item(v-for="item in items)
a {{item.name}}
2) and the second
card(v-for="item in items")
div.content
img {{item.photo}}
div {{item.desc}}
button Details
The main idea is when i click on list item i want to toggle the card with the same id, as list has. I use one file conponent management from vue webpack template.
A lot of folk seem to be trying to use Vue without a store. Could you be one of them? Perhaps because the store is not strictly part of Vue? Perhaps because the docs spend more time on parent-child communication, events etc (complicated) than on state management (simple)? Perhaps because OO has rotted our brains?
Vue wants to talk to a store. The whole point of bidirectional binding is to separate state from markup. The whole reason why this is such a genius idea is that many (most?) items of state have more than one representation on screen, like your items array. Your store, which can be as simple as a js object in window scope, should contain all your page state at a given moment. You should be able to copy-paste the store between pages, and be looking at the same thing on screen. The important qualities of a store are...
that there's only one of them.
that you 'normalize' your store so that an item of state is only stored once, and there are minimal dependencies between items of state.
Your items array should be in the store, and both components refer to this 'single source of truth'. If you're using other people's components, then you'll need to feed them some properties, but properties are for creating tunnels through Vue components to link leaf components with your store. Your items are your state, and state shouldn't generally live in Vue stuff. Does that help?