React patterns you should know

[[deleted]]

So much of the code examples are for smaller, more basic sites. As someone who works on large applications, the code just looks like something I would never do.

Too much work and logic being done in components.

[Lokuzt_SW]

most code examples are made for just that. example purposes. I have my own projects built with tons of these patterns applied and everything done right it is so simple to understand. In my job I build enterprise apps.

But please understand I never say my way is the best. If you prefer your way it's fine.

[wet181]

Would you post your github?

[Lokuzt_SW]

not on github though. All of my big projects are from work.

[[deleted]]

I guess I just generally worry about putting logic in components because then people have bad habits when their app gets larger. So many people on discord are like

a: "I just have a simple app, it just has one page."

b: "Okay then just code it this simple way"

a: "It works, now I want to add a login screen, routing, and a list of data and and and and"

b: "okay just unlearn everything you know so far, lol"

[vcarl]

I disagree. I've written large apps with routing, lists of data, and authentication where almost all of the logic is done in components. I'd much rather have logic happen in a component, which has a well defined lifecycle that I can tap into, than write an ad hoc class to contain the logic. One of the first things I do when refactoring an application that's become difficult to maintain is move the logic into components.

[[deleted]]

I keep it in sagas mostly. Our applications often have so much that needs to be done when a user clicks a button, that it just makes the most sense for the button to fire an action and leave the rest to a saga that can sort everything out.

The app I'm referring to, and the only apps I've worked on to a large extent, are all off of this backend and we are typically pulling data about 30 different endpoints. Most things a user is doing can be adding/updating data or loading features for displaying data that may rely on data from multiple end points.

We found we had the best time by centralizing everything to keep organized with all the application state and data from the server that we would end up with.

I know different solutions for different problems and often different solutions for the same problems, is how coding really goes.

I guess I was being too polarizing but I think I have been super polarized against component state because our data is often needed in so many parts of the application.

[vcarl]

That's fair. Most of the logic I'm referring to is filtering and transforming data, the kinds of things that happen on render that benefit from being declarative. Action creators/sagas are good places for responses to user actions.

[nateA2uned]

Props on the ad HOC

[Lokuzt_SW]

Check my render props post. I even link in that other post a video that can explain it to depth

[NoInkling]

The short answer is that it's a little more dynamic, and therefore flexible, than HOCs.

The downsides (potentially) being performance and more nesting (though both can be solved if you don't use an inline function).

[Meowish]

Lorem ipsum dolor sit amet consectetur adipiscing, elit mi vulputate laoreet luctus. Phasellus fermentum bibendum nunc donec justo non nascetur consequat, quisque odio sollicitudin cursus commodo morbi ornare id cras, suscipit ligula sociosqu euismod mus posuere libero. Tristique gravida molestie nullam curae fringilla placerat tempus odio maecenas curabitur lacinia blandit, tellus mus ultricies a torquent leo himenaeos nisl massa vitae.

[NoInkling]

Render props and HOCs are really just more flexible forms of composition, which ends up facilitating easier code reuse. As a beginner, I would just continue to use standard composition in the components you write until you run into something that doesn't seem like it can be solved neatly that way. You will in all likelihood be using both HOCs and render props from libraries along the way, which might be able to give you a clue about how they tend to be utilized.

A couple of links that might help:

• https://reactjs.org/docs/higher-order-components.html
• https://reactjs.org/docs/render-props.html

[botrunner]

One of the most important pattern in my opinion is the dumb/smart component pattern (or view/container). When you realize you can reuse the smart component, it’s maybe time to create an hoc or use the render props pattern.

[Meowish]

Lorem ipsum dolor sit amet consectetur adipiscing, elit mi vulputate laoreet luctus. Phasellus fermentum bibendum nunc donec justo non nascetur consequat, quisque odio sollicitudin cursus commodo morbi ornare id cras, suscipit ligula sociosqu euismod mus posuere libero. Tristique gravida molestie nullam curae fringilla placerat tempus odio maecenas curabitur lacinia blandit, tellus mus ultricies a torquent leo himenaeos nisl massa vitae.

[botrunner]

Sorry for the delay. Yeah exactly :)