Can someone give an example of an app that is extremely well suited to Flux/Redux?

Question

If the example could help me understand the answers to the following questions I would be very happy: Should you use a Flux/Redux store for data that is unlikely to change throughout the apps lifecycle? And if most of the data in your app is like this should you even bother to use a flux/redux store?

I ask the question in the title because the vast majority of apps seem to be of a similar kind to mine (be it more complex) as described below. I somehow see Redux as a framework designed for apps with internal data that gets mutated (hence the large abundance of counter examples in Redux tutorials).

In my case, the first screen of my app will prompt the user to select a hotel from a list. Once selected a menu structure specific to the selected hotel will appear (which is amazingly easy with react), created from an api response to the server. Once a hotel is chosen it is unlikely that it will be changed, but possible, in which case a totally new set of menus will be loaded. The rest of the app will simply be pushing data to the server by means of form submission. And receipt confirmation for the user from the server.

Answer 1

Suppose you have a component tree that looks like this. Component A is the root. There's a button in Component G.

Component A --> Component B --> Component C --> Component D --> Component E --> Component F --> Component G

Now, let's say you have another component, Component K, which is nested as follows:

Component A --> Component H --> Component I --> Component J --> Component K

Component K is a simple view that takes in a prop and renders a span tag with the value of that prop. Component G contains a button that, when clicked, changes the value of the prop that Component K renders.

Now, the React-without-Flux way to do this would be to have Component A own the state and pass it down as a prop to Component K. Component A also would have a method that modifies that state and passes a reference to that function as a prop all the way down to Component G.

That doesn't sound so bad if you do it just once, but what if you have dozens of state variables? What if your components become even more nested? Your controller-views become very difficult to manage, and you will be passing dozens of props to intermediate components that won't even use those props (only pass them down to their children).

Flux allows you to reduce the complexity of your controller-views. Your controller functions can be placed in separate modules, which can be imported into the components that need to use them. Components that need to access state can subscribe to the store that contains that state.

As far as I'm concerned, this is the primary reason to use a Flux pattern.