Child components are not able to affect the parent

[mostakimvip06]

Thanks to the large community gathered around the library, solutions to most of the problems encountered can be found ready-made on the Internet. The library is used by many well-known brands that are probably a frequent place of visit for most of us. These include Facebook, Instagram, Netflix, AirBnb, Imgur, PayPal and DropBox.

The main distinguishing features of the React library are:

Virtual DOM tree, thanks to which the application does not have to rebuild itself completely when changes occur. It only finds places that differ from the previous version and only those components are rebuilt.
Another feature is the extension of the Javascript language called JSX , thanks to which we can use HTML tags or React components in JavaScript, among other things . What are components? They are the basic "building blocks" in the library. Their task is to divide the created page into smaller, reusable components.
React has many other conveniences. If I've intrigued you with this information, I recommend that you read the official application documentation. Its Polish version is available. Also, take a look at our other post, which discusses writing a blog in the Gatsby framework based on the React library .
Due to its features, React is often used to write SPA applications, or single page applications . This means that the page has a single HTML file, and is not reloaded when browsing.

One-way data flow
Data flow in the library can be described as follows: the state of the application/component is sent to the view , which is created based on it. In the view, we can register actions that change this state, for example, clicking a button. Based on the changed state, the component view is rebuilt, for example, the counter and its dependent components ("children"). We have a kind thailand telemarketing data of dependency wheel here. Data flow in the React library is unidirectional (English: Unidirectional Data Flow ), which means that data flows in one direction from the parent down to the children. We call this data props . Child components are not able to affect the parent component. This solution has a number of advantages, such as:

Easier application debugging.
We know where the data is coming from, so we can find errors faster.
We have a lot of control over the flow.
The relationships between components are clearly defined.
Thanks to the unidirectional data flow during the state change caused by a given action, the entire application does not have to be rebuilt. It is enough to change the component in which the action occurred and its children. The idea of ​​unidirectional data flow comes from the flux architecture , also proposed by the Facebook team (Meta).

Flux Architecture
React itself does not force us to follow a method or set rules for writing the architecture of our application, which can be considered both a disadvantage and an advantage. For the user, this means complete freedom in deciding on the architecture, which can often result in many errors, especially in the case of programmers with little experience. However, the undoubted advantage of such a solution is the low threshold of entry to the library , we can start writing a simple application almost without knowledge of React.

Here comes the Flux architecture , which is not mandated, but recommended for use. Flux is based on a design pattern called CQRS (Command Query Responsibility Segregation), which was described by Bertrand Meyer and consists of separating queries from updates. This means that the code segment responsible for retrieving data is separated from the code segment responsible for modifying data.

In the official Flux documentation we can find an infographic that well illustrates Flux's assumptions.


What we see here is the unidirectional data flow described earlier:

Actions: Activated by events in view, go to the Dispatcher.
Dispatcher: Its task is to receive shares and further distribute them to the appropriate Stores.
Store: Responsible for storing application data. Additionally, its values ​​can only be modified by actions passing through the Dispatcher.
View: Built and updated based on the state (data) from the Store. May contain UI elements that allow sending actions, e.g. click.
There are many different implementations of the Flux architecture. In the case of React, the most popular combination is Redux, but we can find many other implementations such as MobX, Vuex, Alt, and Reflux.

Redux – an implementation of the Flux architecture
Redux is one of the most popular libraries for managing application state. It is most often used in tandem with React, which does not mean that it is strictly limited to such use. It can go hand in hand with various frameworks or even with Vanilla Js. As I mentioned above, Redux is an implementation of the Flux architecture . The creators themselves describe that managing the application state with Redux gives it predictability and ease of tracking data flow. However, something comes at a cost - many people complain that even to perform simple operations, you have to write a lot of the so-called boilerplate, i.e. additional code.

In React itself, Redux – by creating a global store – makes it easy to transfer state between components that are not direct children. Additionally, the library community is really big, so the user can find many tutorials or solutions to encountered problems.

Many such libraries lose their advantages as our application grows and expands. However, this does not apply to redux, because thanks to its architectural assumptions and the separation of business logic ( what is business logic and more about application design ) from application views, it is predictable for the person who creates the application as well as for the new person who will then develop it.