On flux architecture: what data should be put in the store


On flux architecture: what data should be put in the store

I believe many people who have used react and Vue have thought about this problem. The emergence of react brings the design concept of flux. From react’s reflux and Redux to vuex of Vue, I think it’s time to summarize.

There have been too many articles on the mechanism of flux, so I won’t say more here. If you don’t know, you can refer to Ruan Yifeng’sIntroduction to flux architecture。 Here is a brief introduction to the three mainstream flux architectures:

Reflux is the first flux architecture I came into contact with. It simplifies the structure of flux and brings some convenience, but it is not good enough. Its stores are not unique and allow you to create multiple stores. If it’s not handled well, it’s hard to maintain.

Redux has done a great job in this regard. It has only one store, and introduces the concept of immutable to further improve the predictability of the store. But its asynchronous operation is a pain point. Although it is an excellent middleware such as saga, it is still easy for novices to get dizzy.

Vuex does a good job in this aspect. It limits asynchronous operations to the actions phase and reduces many cumbersome steps. Its store is also the only one, but you can use this. $store to reference it anywhere. It is convenient and will also bring some hidden dangers to students with bad habits.

Well, then we should get to the topic.

Multiple views

Two days ago, I had a disagreement with my colleagues on what kind of data should be stored in the store, so I checked a lot of data and discussed with some technical giants. To sum up, there are two mainstream views:

  1. Store only stores public data, and the data and status of components are maintained by themselves

  2. All data should go through the store, and the view layer only displays the data, which is also the practice recommended by flux officials

In particular, this paper discusses the application of spa. Therefore, unless otherwise specified, the components here refer toPage level components, or routing level components, not single components. In addition, flux has no official concept of data, and all data are status. Then why should I take it out? It will be said later.

Those who hold viewpoint 1 believe that only public data and cross component data should be put into the store. The advantage is that the store is small, the data in the page component does not have to go around, and the development is simple.

People who hold viewpoint 2 think: Er, it seems that I have similar ideas myself. In order to avoid bringing personal thoughts into my mind, I don’t presume others’ ideas here.

Store location

At present, all parties have a certain number of supporters. To clarify this problem, we must first position the role of the store. As a data center? Or as a global variable warehouse? Or another idea?

Since I came into contact with flux, I have always followed the second idea, but not exactly. What is a store? Literally, it is a storage, a local storage. Let’s take a look at our current front-end and back-end interaction. Pull = > show, and then pull = > show again. Every time you switch the page, you must pull the data again. Why can’t we do better? How about positioning the store as a local snapshot of server data? Yes, that’s my idea.

In traditional application development, our applications interact directly with the database. But the front-end is not good. Aside from the need for back-end programs to provide interfaces, the front-end and the database are separated by the HTTP layer, which produces a huge delay. So why can’t we create a data snapshot locally? Is it appropriate to use store to do this?

You might say that localstorage and indexdb are more appropriate to do this. Not to mention the size of localstorage, you also need JSON for data maintenance. Indexdb is not easy to operate. Moreover, their access speed and store are obviously not the same level (although users can hardly feel the difference).


With the exception of sideways data such as autocomplete, all data pulled from the back end isPage level componentsAs a unit, they are stored in the store as a local snapshot of server data. In this way, when users switch pages, only the view will be destroyed. Each time a user enters this page, he will first get a snapshot of the data, and the store will query the server for the latest data at the same time. If there is an update, you can prompt for new data (such as Sina Weibo).

As for status (yes, as mentioned earlier, I treat data and status separately. Data refers to business data, while status, I understand it as behavior status), unless it is a global state, whether you are a page level component or a single component, you can maintain it internally.

In particular, the data in the store should be kept as the original server data snapshot as far as possible, rather than making any change, similar to Redux’s immutable idea. The results of operations such as add and del should not be put into the store, but just a state feedback, which should be digested inside the component.

In this way, there are only two pure things in our store: global state and business data (server data snapshot).

Furthermore, we can use the store as a local cache with the help of local storage to achieve the effect that restarting the app can immediately restore the site.


  1. User experience. For pages with high switching frequency, the user experience rises sharply. Imagine that if the data is placed inside the page component, the data will be destroyed after leaving the current page, and the user will return to the page again one second later…

  2. Resource optimization reduces requests to the server. Data with a long update cycle, such as user personal information, can be requested only once

  3. Predictability, the data predictability advocated by flux has become possible, and various data tracking tools have been able to develop their skills (the data tracking of wechat applet development tools is very good)

  4. Readability. The component only has view logic without modal logic. The business logic is clear and easy to maintain

  5. It is highly extensible. For example, you need to add permission control and data filtering, which can be easily solved at the store level. And if the business data is inside the component…

  6. Uniformity, unified access of all business data and convenient management.


Let’s take a look at what people with view 1 oppose:

  1. The store is huge, which is the first thing that people who hold view 1 oppose. However, for spa and modern PC, can your spa store be in G?

  2. Writing is cumbersome. Well, that’s a reason. However, for the advantages it brings, this sacrifice is nothing, right?

  3. Data aging, it was mentioned that one-time data (such as order settlement) should not be put into the store. Yes, we can clean it manually when the page is destroyed, can’t we?

  4. A single store file is difficult to maintain. It was mentioned that all business data operations are in the store, which is difficult to maintain. In fact, with the current construction tools, we can cut out the stores of each page component separately and merge them during construction, which will not affect maintainability.

  5. Data pollution, some people worry that if so much data is put into the store, it will cause pollution. For this, both Redux and vuex support sub stores. That is, the concept of namespace. For example, store.pagemodule1 and store.pagemodule2. It is not a problem to cooperate with some testing tools (such as Mocha) to detect duplicate names

What else?

In the actual development process, there is another problem often encountered and often asked: public page components are easy to load non self data. For example, on the article details page, if you browse Article 1 first and then Article 2, the content of Article 1 may be displayed first, which will be very strange. In fact, this is also an easy problem to solve. When entering a page component, the first thing to load is the initialstate. Then, flux pushes the data in the store. At this time, you should verify the article ID and assign it only if it is your own data.

Applicable scenario

I remember someone said, “if you don’t know whether to use flux or not, you don’t need it.” Dan Abramov, the author of Redux, said, “flux architecture is like glasses: you will know when you need it.” if your business just needs a global variable warehouse, will flux be too heavy? For most spa scenarios, I think this idea is feasible. In addition, for applications with more one-time data, this idea may not be suitable.

Responsive store scenario

I think in the most ideal state, the flux architecture can go further, make the store more pure, and maintain the data by itself. Specifically, AJAX is placed at the store level. When the requested data does not exist or is too old, it will be pulled automatically without using actions to process the logic of pulling data.