SIGN IN

React Lessons. Lesson 12.

Stay Informed

It's important to keep up
with industry - subscribe!

Stay Informed

Looks good!
Please enter correct name
Please enter correct email
Looks good!

react_12

Hey all! Right now we will check up your home task and give you some valuable comments that will help you with your future work with React. To make it more convenient, you will need to see your code, so, switch to the respective commit and we will continue. Let us start with connect. We need connect to work with store. There is also another way: if you can transmit data using common props – do it! For example, in containers/Articles.js  we refer to store in order to take out the needed articles from state:

While in Article/index.js, for example, we do not use  conncet . The component starts to render by itself. And regarding  containers/CommentList.js we make this component “smart” again by using connect, or otherwise we won’t have a chance to reach it. We don’t have these comments inside state – they are kept within store and we need to reach them somehow. That’s why the only right way is to use conncet .

There is another way – to extract comments using the handwritten helper directly from the article. For example, in the render method of our CommentList.js. By doing this, we get the impure function render and a risk of various unpleasant situations. For example, when you do action  that updates the comments, but does not deal with the articles, as a result this component does not get updated at all. It happens because the only update will take place on the highest level, and it will be connected with the update of filtered articles in containers.js/Articles.js .

Redux will check whether the list of filtered articles corresponds to the previous one and will conclude that nothing needs to be updated. That’s why we add connect whenever we need to refer to the data we lack at the moment. We need to choose: to take the data at a higher level or add connect at a lower level. This is an issue of balance that can hardly be explained as React lacks any logical formula on that issue.

We won’t analyze your home task in details, and you will have a chance to see an example of its completion in our repository. And now let us move on to some aspects of executing this task, so go to the respective commit following the link above, and we will move further.

So, how do we work with forms? Let us look at the file components/NewCommentForm.js . We store the values for our inputs inside state. In our case, these are user and text.

Next we transfer the values from state to inputs,

And within the event onChange we transfer callback  that is enabled to change the value – in our example, the execution is the following:

Next we can easily bring the data to zero simply by calling setState with empty strings, when the comments are added and inputs are empty:

And now shortly about middleware. These elements need to be written, so they can be easily re-used in the future. They are a part of the app architecture that will provide the whole interaction. Your every action will go through this middleware from the very moment you connect it. That’s why it will be great to provide multiple use instead of applying it only once for a particular situation. For example, you should not write middleware for adding the comments’ idMiddleware for adding a random id can look like this:

The greatest advantage of React+Redux is its transparency. This One-way data flow is absolutely perfect as you are always aware on every stage of what’s going on. You know, once submit for adding comments has taken place, they go to Action creator, next they go to a chain of your middlewares, and in each of them you see obvious changes: in one of them you will get an id added, next everything will be logged (through  logger.js ) and then transferred to reducer . Only pure functions are contained there, so it will be easy for you to control the process. Eventually all of these will lead to an update of your DOM. That’s why you will desperately need to check every of these steps for debugging. If you add middleware  for different, but in fact all of the same type  actions, it will be hard to supervise the process later. Create middleware  in a more transparent way.

But let us come back to our middleware . In AC/comments.js we add a flag – withRandomId – and later in middleware  we check it. If we’ve got the flag, we add a random id  and let this action go further. Later in reducer/articles.js we extract this random id right out of action :

and work with it:

And the last thing. Take a look at reducer/articles.js, in particular at Record :

It is an immutable structure. And while you won’t do anything with the primitives, it is quite possible to do with comments. For example, by using push for comments you mutate them with this method, since it is a simple array. With this action you lose everything that  immutable structures bring to you. When you change something inside, Immutable.js thinks nothing has really changed. It means, we do push  instead of concat:

as a result, nothing returns. The very data have changed, but nothing will happen and all the elements will be the same within return.

And a few words about bad effects of abort optimization. In our previous lessons we used a lot of lifecycle hooks in containers/CommentList.js , including shouldComponentUpdate(). It checked whether isOpen changes. If it does, we update this  CommentList and if isOpen does not change, we give an explicit command to React not to re-build the component. This is the type of optimization that prevents us from doing a component render again, but this action is quite risky, so do not use it at every step.

We created shouldComponentUpdate()and checked whether isOpen changes. At that moment it was a great type of optimization as whenever something that didn’t deal with CommentList, which could only open or close, changed, we didn’t really care about it. But the app has got more sophisticated, extra logics gets added to the component, and as a result if we add shouldComponentUpdate again:

the comments won’t be added unless we start to open/close them. So, why does it happen? Because of abort optimization. Comments get changed, while isOpen doesn’t. As a result, the component does not get rebuilt being more interested in  isOpen . So, be careful and use it only in those places where you really need it.

Carefully learn and analyze everything we’ve done in frames of your home task and we will move on. Good luck, see you later!

see-you-soon

We are looking forward to meeting you on our website soshace.com

About the author

Stay Informed

It's important to keep up
with industry - subscribe!

Stay Informed

Looks good!
Please enter correct name
Please enter correct email
Looks good!

Related articles

The Path of the Self-Taught Programmer: Avoiding Common Problems

In this article, we’ll explore how a self-taught programmer comes to be: which education opportunities they can utilize, which problems they may>>>

Programming

Introduction to GitHub Desktop: A GUI Enhancement to a CLI Approach

In this article, we'll explore various use cases of GitHub Desktop -- GUI software designed to ehance your git workflow. Does it hold up against CLI>>>

Programming
29.10.2019

Python Array Explained and Visualized

In this tutorial, we’ll delve into how Python arrays work, what their limitations are, and how you can use them to maximize their>>>

Programming

No comments yet

Sign in

Forgot password?

Or use a social network account

 

By Signing In \ Signing Up, you agree to our privacy policy

Password recovery

You can also try to

Or use a social network account

 

By Signing In \ Signing Up, you agree to our privacy policy