Thinking in React

Let’s build

The intended audience of this blogpost is a beginner in React.

Section 0: Introduction

The purpose of this blogpost is to build a very simple react app but we will do it by following a systematic approach as described in the react documentation here.

After reading this blogpost, I would be happy if my readers were able to pick up some of the thinking processes explained here and intuitively incorporate it into their daily workflow of learning React and that would be the key take away of this post.

The reader need not worry about the lack of code in this blogpost. The primary intention of this blogpost is to expound to the reader some of the thought processes involved while developing websites in React. Of course, the code to this project is provided as a link to the GitHub Repo.

Section 1: Main Content

First, let’s take a look at what we are trying to build. 👇

The web-app we are going to build using the systematic approach as prescribed in the React documentation

As we can see in the app there are bunch of questions and for each question there is a button associated to it and when the user clicks on the button the app reveals the answer.

To build this website/web-app using React the documentation advises us to start with a mock as in a demo website provided to us by the designers, break it into pieces and build a component hierarchy. Think of “break it into pieces” to mean that we are labelling each and every discernible part of the app.

So now, let’s label each and every part of the app and later decide the component hierarchy structure of the app.

I have labeled each and every discernible part of the app as follows. Just take a look at it 👇

The app with it’s distinct parts labeled.

Now let’s decide on the components and their hierarchy that we need to build for this app.

Let’s compose one component called QAcard from parts 4,5,6 and 7.

We can render 5 and 7 inside QAcard using conditional rendering, props and state change. For part 6, we will build a component called ExpandBtn.

Now the hierarchy structure of QAcard looks like 👇

Let’s compose another component called BoxOfQA using the component QAcard. This BoxOfQA component represents the part labeled as 8. The component hierarchy structure of BoxOfQA looks like 👇

Let’s create a component called Content which represents the part labeled as 2 and this component will contain both part 3 and the BoxOfQA component. Let’s also not implement 1 as a component.

Now our entire component hierarchy will look like 👇

Now that we know our components and their hierarchy, let's do some coding by building a static version of our app. Before coding it would be good if we were to ponder on the functionalities of these components. It would be better if we ask ourselves questions like

1. What is the responsibilities of each components?
2. Are their some common responsibility between two different components?
3. Is a component redundant?
4. Can we envision a different component hierarchy?

Anyways, regardless of the answers to the above questions I am going ahead to put together a static version of the app.

According to the React official documentation “by the end of this step, you’ll have a library of reusable components that render your data model”

I have used create-react-app and the structure of the src directory and the code of the static version of the app can be read here.

My implementation of the static version of the app looks like 👇

static version of the app

At this stage the buttons don’t work and the UI is not responsive. Now let’s make it responsive.

It is time to identify all the data that we are passing to and from the components.

So now, let’s identify all the data in our app.

As part of the project setup we have a file called data.js which contains as the name suggests json data of the questions and answers that we display in our app. We import this file into our app in the BoxOfQA component and consume it at QAcard component. So basically in our simple app this is the only data that is flowing from a component to another component. And the below diagram is emphasizing the flow of data between the two components. This data however does not represent a state as they don’t have to change with some user interaction.

Flowchart showing the flow of data from component BoxOfQA to QAcard

Since we now have identified the data in the app. Let’s figure out all the states that we need to render reactivity to this app.

We definitely need one state that updates whenever an user clicks on the button. I think that’s it. With this one state we can accomplish our goal.

Using this state we can:

1. change what is been displayed on the button
2. display and not display the answer to the question.

Now is the time to figure out where we must place our state for this we must consult our component hierarchy chart. We have two options here:

1. this state can be privately managed by the button and it is not wrong because the state happens due to we clicking on the button and therefore we can make it the sole owner of this state but that could lead to a problem i.e., we may find it difficult to conditionally display the answer to the question
2. we can lift the state up and place it in a component where we can do both i.e., update the button and conditionally render the answers

If we look carefully at our hierarchy chart there is one suitable place to keep our state and that is the QAcard component.

To recap we have figured out the main data in our app, we have decided to create just one state, we have decided to place it in QAcard. Now let’s implement it.

After implementing the state the app behaves like 👇

Final version of the app.

Section 2: Conclusion

Since the app was very simple. It was easy to figure out the components and decide their functionalities. It was easy to figure out the flow of data among the components, the state, etc. But in a normal react project these activities consumes a lot of time. Ideally you must try this approach on a larger project and check if it’s viable and makes you productive. And I think it does make you productive.

Section 3: References

1. My GitHub repo containing the code to the above app.
2. Thinking in React
3. This GitHub repo was used as a reference for the code of the project used in this blogpost.
4. The author of the above GitHub repo has hosted the app here which looks exactly similar to the app implemented in this blogpost.