CODEWITHSUNDEEP
reactjs-flux
Andrei Gabreanu
Andrei Gabreanu

Reputation: 144

How to manage state in a Flux/ReactJS app with Stores?

In a FLUX/ReactJS arhitecture, I am curious if the following approach violates (or is just not recommended) the FLUX flow.

1) We have 2 stores. Store A & Store B.

2) We have one "App" Component which has its State set from Store A and passes it down to Component 1 and Component 2.

3) Component 1 uses the data from the received "this.props" and renders stuff.

4) Component 2 uses data from the received "this.props" but also has its own state based on Store B (the same way "App Component" has its state).

From what I understand - ideally - I would make the "App Component" listen to both Store A & Store B and pass everything down to the other components.

However, in a real life application, you'd have let's say 100 stores, each with its own conditions (you could say Component 2 doesn't get rendered if a certain combo of data is not met, etc). That would make the App Component a GOD-like component which handles so much stuff. Impractical in my mind.

In my mind, you still get a one-direction flow of data even if you don't have a top component managing all state and passing it down to the components - since the state is still dictated by the Stores, not by the components themselves (and you trigger events via Actions->Dispatcher->Store). This is especially good in my mind if you want to encapsulate a certain behavior in a component.

Imagine the following scenario:

AppComponent -> AuthComponent -> LoginFormComponent

AppComponent -> ListItemsComponent -> SingleItemComponent

Wouldn't it be weird if AppComponent knew about the "AuthStore" state, just so it can pass it to the AuthComponent via props ? Wouldn't it be better if the AppComponent knew nothing (in this example) and just renderered the 2 children; The AuthComponent would listen to the AuthStore and pass down info to the LoginForm; The ListItemsComponent would listen to a ListItemsStore and pass down the needed info to SIngleItemComponent etc..

Which approach would you guys take?

Upvotes: 1

Views: 113

Answers (1)

shtuper
shtuper

Reputation: 3916

Theoretically If your lower level component is completely isolated and there is 0% chance that, depending on its state, you would need to change the state of higher level (or the same level) components, then there is nothing wrong with managing its state within the component itself.

There are downsides however:

  1. If later you decide to use the state of the component higher in the hierarchy you'd need to refactor.
  2. It makes a component less reusable. You'd need to have same store, same actions etc. whereas if you received state via props you could plug it into other project much more easily.
  3. It makes it harder to test.

I would say that if it's a large independent component, with many lower components it makes sense to keep the state within it, but usually there is only one such component in the app. If it's more of a small, one purpose component, there is no point in doing this.

Upvotes: 1

Related Questions