Hello. At this year's FE-CONF, I prepared a presentation on the topic of rethinking components. Most likely, if you're a front-end developer, you might have thought about what to write and how to separate components.

After this presentation, you might take the perspective of components to the next level.

Let me start the presentation. I'm Jihyeok Won, who is going to start the presentation.

I am working as a software engineer at Danggeun Market, Thirdparty Team. I am a GraphQL Korea Organizer, and develop products as a full-stack developer, from client to back-end.

At first, we are going to look at the components together.

Let's take a look at what is needed to make a React component and the materials that prevent maintenance.

Last weekend, I spent time in the suburbs of Seoul. I went to a very pretty dessert cafe and they sold a white fresh cream cake with strawberries on it.

What do you need to make a cake like this? I don't know much about baking, but I think that flour, sugar, and eggs would be definitely needed.

In other words, the three ingredients, flour, sugar, and eggs, are definitely needed to make a cake.

In other words, a cake depends on flour, sugar, and eggs.

Expressing this in another way, a cake can be expressed as having a dependency of flour, sugar, and eggs.

We use the word, dependency, a lot. Conversely, what are React component dependencies? Likewise, let me explain it in another expression.

What would be needed to create a React component? As we all know, React components can receive necessary things through props and hooks.

This can be seen as a functional classification of dependencies of a React component. So what are the characteristics of dependencies we pass through props, hooks, or imports?

we pass through props, hooks, or imports? At first, there is style. As you all know, style means CSS.

Mostly, you might write a CSS or SCSS file on an external file, and then import it into the component.

Therefore, style is a dependency for a component. Secondly, there is specific custom logic which is used in the component. It is used to perform specific actions to manipulate the UI or to give intended side effects to React components.

Usually, it is written in the form of a custom hook. The third is the global state.

Global state refers to the state of the client caused by user actions. Usually, it includes login information, opening and closing the entire menu, or the expression of URI, etc. The last dependency I would like to introduce is the Remote Data Schema.

Even if I thought deeply while preparing for the presentation, I thought it would be better to express it as it is, rather than changing it easily.

So, I wrote it as it is. The remote data schema is remote, in other words, it means data that is downloaded from the API server.

The word schema means a container for data. It would be better to think of it as the content and form of JSON data sent from the API server.

In my opinion, there are four characteristic classifications of the dependencies of React components.

of the dependencies of React components. Some of these dependencies deserve a closer look. That is the remote data schema. Relay documentation, one of the GraphQL clients created by Facebook, has this phrase.

Let's read it together. The vast majority of products say they want one specific behavior.

What I'm saying is that it fetches all the data it needs while displaying the loading indicator and then renders the entire view when the data is available.

Perhaps, it would be a little bit hard to understand this, so I prepared two product videos.

Let's take a look. On the left, the loading state is located in each component, and it feels like it is dripping when it is loaded.

On the right, when the loading state is over, all the components are ready and it feels like it is popping up and floating at once.

Which of the two products do you like more? I think you probably all want the right. Now, let's go back to the cake story we talked about earlier.

Let's put strawberries on the cake once more. However, I thought I would only need strawberries to put strawberries on the cake, but I found out that I needed additional whipped cream.

In other words, Strawberry cake would mean an extra reliance on whipped cream, unknowingly.

It means that there is whipped cream in the hidden dependency of strawberry cake.

Now let's assume that we want to add new information to our React component. Then, in order to add new information, we will define new Props to receive the information.

Here the component needs not only new information but also other modifications.

I want to express this as a hidden dependency of a React component. Now let's take a look at the scenario.

For instance, let's assume a situation that involves adding new information to a general bulletin board model. Now let me tell you an important point.

Let's assume that while expressing the loading shown earlier, we create an action to display the entire page just in time when all the data is loaded.

First, we will modify the Props of the Article component to receive new information. After, I would modify the rendering part of the Article component.

And I'm going to edit the props in the post list, and then I'll edit the useEffect Hook of the root component.

Therefore, in order to express new information, not only the information but also the root component and the transformation of the components in the middle are inevitable.

Therefore, this becomes a hidden dependency with the remote data schema.

Even if you set aside data storage to avoid props drilling, if you do page-based routing, you would finally rely on the root component.

Let's take a look at the entire React component that we analyzed a bit. Now, let's look at how to sort these dependencies one by one.

The first is to put them together. It is called Co-locate, Co-location.

I would like to introduce the first refactoring principle: If you have similar interests, keep them close by. While editing something, when the files move away from each other, your concentration tends to be distracted.

Therefore, if you have similar interests, it's a good idea to put them in the same file or right next to them.

Coming back to the dependency model earlier, which of the four dependencies would be the easiest to put together?

First of all, since the global state is used by several components, it seems difficult to keep them together.

Style and logic seem to be easy to put together. So, let's change it embedded in the component like this.

Usually, you use CSS-in-JS as a solution. This writing method can actually be seen as co-location.

Let's take a look at the code. I've put the logic and styles together inside the component file like this.

Now, when you need to edit a specific part, if you need to edit style and logic, you can edit it together without having to go back and forth between multiple files.

You might be concerned if the size of one component is too large.

In that case, it is recommended to separate the files into different files in the same folder, not in different folders at the top or bottom.

Next, we need to put the remote data schema together. If you take a brief look at how the remote data schema comes down from the API server, you can see how it comes to my component via the root component and other components as follows.

Here, if you receive the data schema through Props, you will have a strong dependency with the root component. Improving this, you can break the dependency by allowing the data to be retrieved and getting the ID via Props and via the datastore.

Let's say you have the following code. As you can see, the TypeScript syntax may be a little awkward for those who have only used JavaScript.

As follows, we are receiving information about a specific post in the field called `article` in Props.

Let's improve this component together. Then, as follows, it could be implemented by receiving only the string value corresponding to the article ID with Props and receiving the data through specific Hooks, in this case `useArticle` Hooks, inside the component.

By doing this, you can definitely see that the dependencies with other components have been greatly weakened.

But you might be wondering how to implement this.

For this, I would like to introduce the second refactoring principle. The second principle is to organize your data based on ID.

Let's say the API response comes like this: Here, it seems difficult to access a specific object based on ID.

But what if you organize your API response like this? It becomes possible to extract specific data with only the model name and ID.

This is called Normalization. There is a library that can help normalization. There is a package called Normalizr.

It would be great to take a look, if you are interested. Then, with this normalized data, we would be able to easily retrieve a specific object from the data store.

This creates another hidden dependency. The point is that the model must be accurately known at the top.

I would like to introduce a concept to make loose dependencies. It is the global ID. Global ID is a system that allows you to uniquely identify specific data only with the ID value without having to pass the model name separately to identify a specific object.

Usually, it is created by string concatenating the model name and ID value.

In some cases, you can also Base64 encode and decode. So let's go back to that example.

While looking carefully again, if you see the name of the Hook called `useArticle` imported through `Import`, you could check that the component is also being injected outside the component that requires the information of Article.

If we replace this with `useNode` hooks that get data through global ID as follows, we can put model information to be used together inside the component.

I would like to go one step further and introduce Global Object Identification, also known as GOI for short.

It is an API that allows you to get the object when you make a request to the API server through the global ID.

If an API is provided on the server side, the object can be called in any context.

These GOI APIs can be used in various ways. First, you can automate the fetching of additional data when a specific field does not exist in the datastore.

To do this, we need to express which field the component is using. You can express which field to use with the following form code.

Then, what would the final data flow look like? First, we normalize the data retrieved from the root component and put it in the data store.

Afterwards, the component we wrote receives the Global ID from the parent component and requests specific data from the data store through the Global ID.

Here, assuming that the desired field is not found, the data location automatically requests data from the API server using GOI.

The request is successful, and the component we write is guaranteed to have complete data at all times.

Second, GOIs are useful when you want to refresh a specific component.

In most cases, the UI exposes a button that can be refreshed or calls refetch when something is modified. By exposing a procedurally callable refetch function in our useNode, we can easily implement the refetch logic regardless of the root component or parent component.

The second is naming. In this chapter, we are going to talk about Props Naming. Let's say you have the following component: A component that displays a simple user profile.

It can be pasted on a post, and it seems to be used for a friend list, etc.

As we did before, let's take a look at the remote data schema dependencies. You can see that this component depends on fields such as name and nickname of the user model and the thumbnail URL of the image model pointed to by the Image field in the user model.

Then we will try Props Naming from now on. First of all, I built it very simply. At first glance, thumbnailUrl, title, title2 in the image on the left, the names seem intuitive, but they are not.

Because it doesn't clearly indicate the dependencies that exist on this component.

Here I would like to introduce a third principle. If you rely directly on it, it's exposed.

In the previous example, I modified it once to reveal the dependencies as they are. It exposes the use of the User and Image models as-is.

But there is another hidden information. This is the relationship information between the User and Image models. Let's take a look at this information.

Then, props will be created as follows. You'll probably find it a lot more intuitive.

However, expressing information from multiple models in one component is also a kind of signal that the separation of concerns is not properly done.

Therefore, if you separate this component, you can separate it into a User model and an Image model like this. But, as mentioned earlier, since the parent component has to precisely match its shape, you would probably expect that there would be a parent component dependency.

It seems like it would be very difficult to reuse something. Therefore, if only the necessary object reference is received through the global ID introduced above, the dependency is loosened and the component can be made much more reusable.

Lastly, the third is reuse. I would like to think about the reusability of components.

You may think that the reason for reusing components is often for convenience during development.

Today, from a slightly different perspective, I want to talk about reusing components for convenience when making changes, that is, for ease of maintenance.

[A3] 컴포넌트, 다시 생각하기

프론트엔드 개발의 소중한 경험을 공유합니다! 
프론트엔드 개발자에 의한! 프론트엔드 개발자를 위한!

프론트엔드를 개발하며 마주했던
치열한 고민과 깊은 인사이트를 공유하며
여러분과 함께 성장하고 싶습니다!


[A3] 컴포넌트, 다시 생각하기

Scripts