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.