I am having a nightmare trying to figure out how to approach a higher order component. I get how they work (I hope), but as soon as I begin writing my code I stop at here:
const HeadlineHOC = WrappedComponent => props => {
if (props.articleHasArrived) {
return <WrappedComponent { ...props } article={ props.article } />
}
};
I also know how to make that return a class component and add a state instead of a regular functional component but that's almost the same exact thing. Can't I just create a class component and apply a state there anyway, instead of having to go make the extra step in creating the HOC? But thats about as useful I can get when creating a useful higher order component. But its a bum that you can just do that if/else conditional render with a normal function component without the need of making it an HOC. I've read tons of examples, tons of tutorials, tons of explanations why higher order components are good for their examples.
The problem is that I only know that a higher order component is the right thing to do in their situation. But how do I think of creating useful higher order components for my components? How can I acquire that mindset of coming across a problem and immediately knowing that a HOC is the only way to do it? How do you guys approach higher order components as a problem-solving thing?
Dan Abramov probably explains it best in this Medium article. I would read through this to get a grasp of why and how to use 'Higher Order Components'
Related
I understand how to avoid renders through memo, useMemo, and useCallback, my question is not about that. Rather:
Why does React, by default, choose to rerender children that don’t receive props, when the parent updates? It seems like bad separation of responsibility and unnecessary computation. It feels like the child rerender should be left to the jurisdiction of the child.
Why does React, by default, choose to rerender children whose props haven’t changed by value? Essentially I’m asking why aren’t useCallback and useMemo built in by default. Again it seems like an odd design decision.
I am not asking for solutions to make performant React code, rather trying to understand the design decisions. Kindly note most similar questions just have answers where people mention to use the 3 memoize functions. I would just like to understand why React was built the way it was. Thanks!
I'm working on refractoring a medium size app, around 20k lines of code distributed in 20 components. The whole state of the app covers more than 200 properties and to be be faster I built the app by passing the whole state to my child components. Now I'm concerned about the speed of the page.
I wanted to have short and readable components. If I decide to pass single properties I will have some components with 50 properties or more. Does it make sense to do that in order to gain speed?
Thanks for the help
From pattern point of view it is much cleaner to use global state management like redux to share states between components than passing state to child.
In some other cases the solution is even easier and still not require passing states.
YES
React will only render the changes that have been made since the last render, if parts of your child elements haven't been modified they will not be re-rendered to the DOM.
as an example this:
<Content
accounts={this.state.accounts}
showBalance={this.state.showBalance}
withdraw={this.state.withdraw}
deposit={this.state.deposit}
current={this.state.current}
depositAmount={this.state.depositAmount}
handleDeposit={this.state.handleDeposit}
handleRm={this.state.handleRm}
amounts={this.state.amounts}
getWithdraw={this.state.getWithdraw}
/>
could be replaced with
<Content {...this.state} />
I've been testing the performance of animated React components using different methods. The two that seemed most interesting to me were:
In parent component, keep position of children in state and update using requestAnimationFrame then pass props to a bunch of children, which move using translateX() for better performance
maintain position state in each of the children and update its position itself
I saw similar performance between the two. I know that React batches multiple calls to setState, but I'm wondering if it still batches the calls among separate components. In the first approach, setState is only called once per frame. In the second approach, we call setState for each component each frame.
Which is the better practice?
Perhaps I'm not using enough child components to see a real difference, but if anyone with more knowledge of React's reconciliation process has any ideas I'd love to know.
This is not a very precise question. I think I understand the "react lifting state up" paradigm. As far as I know, this is the only clean way for two sibling components to have access to their respective properties.
But doing so, I end up with one tremendous class containing everything : the data information for the properties of all of its child components, and all the functions in charge of updating this information (in charge of calling setState). I'm unhappy with the fact that I'm not able anymore to dispatch into sub-components, the work that has to do with them.
My question is : how to avoid the concentration of all the code in parent components, using react, while keeping the nice clean state/prop mechanism ? Or am I wrong to complain maybe ?
Many people believe jumping directly into redux would be a good idea, but in fact, it comes with lots of computational overhead and boilerplate code.
As a rule of thumb, you would simply move logic up the tree which is relevant not only for child components but also for siblings.
You should also have a look at the concept of Presentational and Container Components.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In creating a React app, I'm currently creating an app where the parent component is handling and managing all the state changes. I am passing down the necessary states and functions to each child as props. Is this the 'preferred' way to do it or should the child components handle/manage their own states?
This approach will work for a while, but you'll soon find that your entire application logic is pushed up to the top component, and that you're passing it down through many nested layers of child components to get it where it needs to go.
One approach is to move various pieces of state down as far as you can (but no further). The Thinking in React article discusses this. So if some state or state-changing functions are only needed by one sub-tree of your application, just put it at the top of that sub-tree. But this can still seem messy, especially when there's a lot of data that's needed all over your app.
The new-ish Context feature can help with the problem of passing data through many layers of components. But it doesn't change the fact that a lot of your state and state-modifying functions are stuck in the top component.
To deal with that, you'll need to look into one of the state-management tools like MobX or Redux. Although Redux is pretty popular, I found MobX a little easier to adjust to. Basically you'll end up moving all of your application data and logic out of your React components, and into their own classes. Using mobx-react, you'll configure those classes (or some of their properties) to be "injected" directly into individual React components as properties. Then MobX will "observe" certain values in these classes, and tell the React components to re-render when they change.
It takes a little getting used to, but I've been very happy with the results. It's frustrating that most React tutorials ignore this issue, or make it sound like you only need MobX/Redux for very advanced use cases. I've found them necessary for anything beyond very simple demos.
It all boils down to one question,
Is the component a re-usable, independent component?
If yes, then it can have its own state and be plugged into any component without any hassle.
It's a good idea to consider these pointers while deciding where to put the state.
There are components that cannot stand on its own but only be used in parent components. In that case, it's a good idea to store the state in parent and drill it down to the child.
There are components that focus only on UI logic and not much, eg. an input box with validation. In these cases, it's a good idea to put the state of input validation in the component itself as the parent doesn't have to care about validation logic.
If multiple child components depend on the data/value from parent, then it's a good idea to put the state in the parent.
The thumb rule is, always store the state in the parent unless the child is totally independent and can be used on other parent components as well.
If a component needs to have its own state, which its parent does not care about, I don't see any reason to define it in the parent.
Defining such a state in the parent will add complexity that is not needed. It will also make maintenance difficult.
It will be much easier to understand the code and maintain it, if local state is defined where it belongs.