1. What is data flow

What is flow?

In mathematics, a flow mathematically formalizes the general idea of “depending on changes in time”. For the moment, define a flow as a collection of changes in response time.

What is data flow

As previously defined, a data stream is a collection of data that changes over time.

The front end is aimed at the current MVVM mode, where the data is the page, and in most cases, the data remains unchanged and the page remains unchanged. So let’s convert, data ==> page, whether the data stream can be equivalent to a variation set of pages. What this is, is our business logic.

Of course, the previous assumption, after a lot of transformation, in fact, there are many loopholes and mistakes. But it can serve as a simple reference.

This is not a definition of data flow, but a way to think about it.

2. The current front-end data management mode

The current three data management methods

  • Functional, immutable, patterned. Typical implementation: Redux.

  • Responsive, dependent tracing. Typical implementation: Mobx.

  • Reactive, implemented as a flow. Rxjs, xstream.

Redux Pattern (Reduck)

The Redux pattern is commonly used as a global state management for the entire application. This is intended only as a tool to improve the ability to communicate across components. The idea of Redux is to act as a data warehouse independent of components to protect data and ensure that data is stable and reliable.

It is easy to understand that redux is a protected, globally used Context (useContext).

Data protection (Dispatch + Reducer) is provided for the native, and changes can only be made using Dispatch. Traceability is guaranteed, data sources are clear, and side effects are well insulated.

Usage:

  • Advantages: Data isolation and traceability of data changes.
  • Disadvantages: Multiple Redux direct complete isolation, difficult miniaturization, easy to inflate action methods.
  • Business usage: Lack of separation design concept for large projects, unfriendly personal control of store data, and difficult to understand and modify logic.

Mobx mode

Mobx introduces a new idea, treating data as a source, having the page change by calculating state when data changes, and automatically performing updates according to Observables based on dependencies. Even with action, there are no forced separation side effects.

Mobx is like binding data and components into dependencies, auto-subscribing and auto-publishing, and components change when the state changes. Tying logic and view directly together should have been a very efficient situation, but because of the depth of the components, the side effects were not clear enough and not friendly enough for personal control.

Flow Pattern (RXJS)

RXJS is somewhat similar to MOBx. RXJS can randomly disassemble and combine all data into a new node, which can be simply interpreted as breaking redux’s state into multiple data nodes. Each arbitrary node can generate new nodes through computed computations.

The flow pattern has no action specification compared to the Redux pattern, but defines a range of nodes for change. Only the defined entry node (the start node of a flow) can be changed. RXJS does not have mobx data change to page change, it can be implemented using useState and useEffect or the off-the-shelf three-party library rxjs-hooks.

The advantage of RXJS is that once all the data sources are removed, all that is left is logic. Side effects are stripped away when the data source is removed (because external side effects can also be removed into RXJS nodes), leaving the concrete logic to be written through apis and pure functions.

Due to a large number of apis, the cost of dismantling Observable nodes is very low, so logical separation is easy and highly readable.

RXJS has the concept of push and pull, and in the normal case of smooth logic, the code of the program should be such that each node transition pushes the next node to execute. After streaming data in RXJS, the component only needs to read and write data to the head node and read data directly to the tail node, and most of the logic is completely removed from the component.

Usage:

  • Advantages: simple logic separation, pure functional programming.
  • Disadvantages: Complex data splitting, redesign, high cost of API learning and understanding.

Ideally, pages are stateless components that change the behavior of data. Data changes trigger logical changes, which change data logically. Data back to the page, this is a whole closed loop, data as the core, perfect to achieve data-driven page.

Nova Recoil

Recoil is facebook’s official recommendation for a status management library. As a “new member,” Recoil makes a lot of trade-outs from the previous three. It has the concept of nodes, atom and selector, but unlike Mobx, Recoil is based on the Immutable mode.

The basic idea behind Recoil is that there is no correlation between Atom data, that all associated data is generated by the selector, and that the associated selector changes as atom changes. This is consistent with the idea of responsive streaming.

React allows recoil implementations to be used as usememo-wrapped context. API usage can be split read-only, write-only, and perfectly suited to optimal rendering, reducing useless rendering.

The first three data streams are neither good nor bad, but each has its own advantages when used in different scenarios.

3. Ideal source data programming

The relationship between data

Data is not generated in a vacuum, and data can lead to new data.

Data is divided and governed by the principle of minimum availability, which is more conducive to development and maintenance.

Individuals define the starting data from which the data is generated as the source data. Some data can be converted to each other, so how to define the source data?

Defining source data

Take a look at the data from a component (page) perspective.

  • Interface oriented programming

In most cases, the data interaction between the front end and the back end is just an interface. Since all real data is retrieved from the server, we subconsciously start with the server interface. The long link of data processing and the large range are very demanding for personal understanding, which I think is not healthy for a large application.

  • Data-oriented programming

Separate the interface request, only care about the component state, for the component aspect, any data does not distinguish between them, the data will be rendered.

Individuals can define data that users can interact with as source data. Because the front-end interface requests are also made by the user’s information requests. For the application, only the user’s operations are unpredictable, and the rest are controllable.

If we encapsulate and extract the controllable logic, we no longer need to directly perceive it when managing, we are directly facing the user’s actions and the page’s responses.

For example, for a single list page, the filtering items selected by the user are the source data, and the list data returned by the interface is derived data. The loading state of the page generated by the interface request can also be derived data or source data.

Redux data model

When using Redux, there is no good way to deal with the hierarchical relationship of data. As a result, the pool of data in store becomes larger and larger, and there is no strong concept of stratification. This is also caused by the difficulty of miniaturization of Redux.

Secondly, REDUx cannot well describe the relationship between data and data. Some people say that computed data can describe the association between data and data, which is no problem in a simple sense. However, the limitations of computed data cannot be supported across REDUx. This is contrary to the principle of least availability.

Because redux’s design pattern is not flexible enough, the logic of converting a lot of data to and from data is backpacked inside pages or components, which is a burden on the view layer.

Responsive stream data model

For ease of understanding, using computed data processing as before, each node can generate a new node at will, but the changes that trigger the whole stream use the results of the whole stream only at the original node (the source data).

In flow mode for a component or page outer data without any hierarchy, each node are flat, if layer, can be layered on business, through continuous joining together, the business logic in series, it is concluded that the results you want, than the original scattered around in logic, series flow logic is better on the readability.

The advantage of streaming data is that the splitting cost is very low, which is more in line with our idea. The code block splitting, so that each small piece of logic is split into a node, the logic complexity becomes very low through continuous disassembly, but the logic will not be scattered because of too much disassembly.

  • There is no hierarchy of solidified data, discrete data, which can be freely defined and spliced.
  • With discrete data, the logic stream, after flexible data, the logic is convergence, not dispersed, to achieve accurate use of data.

Reducx and RXJS data management scope

conclusion

To sum up, in fact, different modes bring different applications for different scenarios, such as quick application and rapid development of Redux, stable data change, and mobx for responsive change, all of which have their own characteristics.

When writing the code, I feel like to build a each frame of the animation (view), and to give each frame why change (write logic, events), logic and views are mixed together, for the control of the whole is very difficult, as you need for the change of the whole animation master, out of the view and the logic, logic only need to change the data, The view only needs to change for the corresponding data.

Refer to the article

Flowing Data – Use RxJS to construct data logic for complex single-page applications

Close reading of The Philosophy of Front-end Data Flow

❤️ Thank you

That is all the content of this sharing. I hope it will help you

Don’t forget to share, like and bookmark your favorite things.

Welcome to the public account ELab team harvest dachang good article ~

We are from the front end department of Bytedance, responsible for the front end development of all bytedance education products.

We focus on product quality improvement, development efficiency, creativity and cutting-edge technology and other aspects of precipitation and dissemination of professional knowledge and cases, to contribute experience value to the industry. Including but not limited to performance monitoring, component library, multi-terminal technology, Serverless, visual construction, audio and video, artificial intelligence, product design and marketing, etc.

Bytedance’s internal promotion code: PEKGTJB

Post links: jobs.bytedance.com/campus/posi…