Managing state on our React Apps

[guilhermebruzzi]

What is to be discussed?

When the app is little to medium size:
Should we use hooks with useReducer or even only a state being passed from a root component by props to the children or even by context?

For large apps:
Should we use redux and it's middlewares?

For apps using graphql:
Should we only use apollo with it apollo-link-state

Describe the solution you'd like

I think the solution depends on the app. I personally like redux a lot and would still use it for medium and large apps (didn't mixed it up with apollo client to really understand the problems with that).

But for small apps would only use hooks but again:
Should we:

• Use state on root component and pass by props
• Use state on root component and pass values by context
• Use useReducer on root component and pass by props
• Use useReducer on root component and pass dispatch as context

[emersonlaurentino]

I think redux for small projects is not cool, just as context for large projects is not cool either. I have enjoyed using state machine in personal projects, would be happy to see a greater adoption within the company.

[salesfelipe]

For large apps that aren't in our current stack:

• I think is reasonable to use redux.

For apps using graphQL:

• I think Apollo Client and its features are enough for manipulating state. I did find a case where it couldn't be solved by using the apollo client or context.

[lucis]

Apollo Client, since 2.5, has been focusing on client state support. I was pretty up-to-date on their efforts when I presented one DemoFriday (starts at 11:50) about client state, but right know I've been only reading their blog announcements.

But, even then, I thought that their solution was pretty complete, specially if your state need match in some way your server data

[klzns]

I think it's really hard to define the right solution for an app. Also I'm afraid doing this will hinder developers from exploring new solutions.

Maybe we should focus on what people should avoid, based on what we learned.

[guilhermebruzzi]

@klzns I don't know, then why we force React as an UI library if exploring new solutions is the goal?

We have patterns on VTEX, we should at least have a guide with recommendations on each case.

We still have to choose a way to make reusable components where the state manager doesn't matter if we are going this way of choose the best depending on each case.

On our Redux approach every component don't depend on Redux, only on it's props to do logic (or depending on the context is ok also), we should enforce this to always be true

[klzns]

What do you think we get more practical like the example you said?

Example:

Guideline: Create separate components for components that render UI from components that get data

Rational: do this because of that, etc.

---

Something on this line. What do you think?

[guilhermebruzzi]

@klzns Yes, we should add TODOs to create this kind of stuff

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this is a discussion thread, the most voted option will be final. Thank you for your contributions.