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] 컴포넌트, 다시 생각하기

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

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


FEConf Korea

리액트 컴포넌트의 숨겨진 의존성에는 스타일, 커스텀 로직, 글로벌 상태, 리모트 데이터 스키마 네 가지가 있으며, 특히 리모트 데이터 스키마는 컴포넌트의 변경 방향을 결정하는 중요한 요소입니다.

컴포넌트를 효과적으로 리팩토링하기 위한 네 가지 원칙은 '비슷한 관심사는 함께 모아두기', 'ID 기반으로 데이터 구성하기', '의존성을 명확하게 노출하기', '모델을 기반으로 컴포넌트 분리하기'입니다.

GraphQL과 Relay는 오늘 소개된 컴포넌트 개선 원칙들을 강제하며 데이터 일관성과 로딩 경험을 향상시키므로, 프론트엔드 개발자가 주도하여 도입을 고려해야 합니다.

리액트 컴포넌트를 효과적으로 설계하고 유지보수하기 위해, **컴포넌트의 의존성이 무엇인지 이해하는 것**이 중요합니다. 케이크를 만들 때 밀가루, 설탕, 계란이 필요한 것처럼, 리액트 컴포넌트도 props, hooks, import를 통해 필요한 것들을 전달받습니다. 이는 컴포넌트의 기능적 의존성으로 볼 수 있습니다.

컴포넌트의 주요 의존성 유형은 네 가지로 분류할 수 있습니다. **스타일(CSS), 커스텀 로직(Hooks), 글로벌 상태, 그리고 리모트 데이터 스키마**입니다. 특히 리모트 데이터 스키마는 API 서버에서 내려오는 데이터의 내용과 형태를 의미하며, 컴포넌트의 숨겨진 의존성으로 작용할 수 있습니다.

새로운 정보를 추가할 때, 단순히 새로운 props를 정의하는 것을 넘어 **루트 컴포넌트와 중간 컴포넌트들의 변경이 불가피하게 발생**하는 경우가 많습니다. 이는 리모트 데이터 스키마와의 숨겨진 의존성으로, Props Drilling이나 페이지 기반 라우팅 사용 시 더욱 두드러집니다.

리액트 컴포넌트 의존성 관리 원칙

첫 번째 원칙은 **'함께 모아두기(Co-locate, Co-location)'**입니다. 비슷한 관심사를 가진 코드(예: 스타일과 로직)는 같은 파일이나 바로 옆에 두어, 편집 시 여러 파일을 오가며 집중력이 흐트러지는 것을 방지합니다. CSS-in-JS는 이러한 공동 배치의 대표적인 예시입니다.

두 번째 원칙은 **'ID 기반으로 데이터 구성하기'**입니다. API 응답 데이터를 Normalization(정규화)하여 ID만으로 특정 객체에 쉽게 접근할 수 있도록 만듭니다. 'Global ID' 개념을 도입하면 모델 이름 없이 ID만으로 데이터를 유일하게 식별하여 컴포넌트의 의존성을 느슨하게 만들 수 있습니다.

세 번째 원칙은 **'의존성 명시적으로 드러내기(Make Explicit)'**입니다. Props Naming 시 의존하는 모델의 필드를 직관적으로 나타내어, 컴포넌트가 어떤 데이터에 의존하는지 명확히 보여줘야 합니다. 이 방식은 재사용성을 높이고 불필요한 의존성을 줄이는 데 도움을 줍니다.

네 번째 원칙은 **'모델을 기반으로 컴포넌트 분리하기'**입니다. 제품의 변경 방향은 대부분 모델별로 정렬되므로, 함께 변경되지 않아야 할 것들은 다른 컴포넌트로 분리하여 유지보수를 용이하게 해야 합니다. 동일한 모델을 사용하는지, 다른 모델을 사용하는지에 따라 재사용 여부를 결정할 수 있습니다.

GraphQL 및 Relay 활용을 통한 개선

오늘 소개된 데이터 의존성 관리 및 컴포넌트 개선 아이디어는 **GraphQL의 Fragment와 Relay의 useFragment 훅에서 영감을 받았습니다.** Global Object Identification (GOI)은 GraphQL 스키마의 표준에 포함되어 있으며, API 서버에 요청하여 객체를 가져오고 특정 필드가 없을 때 자동 데이터 가져오기를 지원합니다.

Relay는 데이터 레이어 프레임워크처럼 작동하여 위에 언급된 네 가지 원칙을 강제하며, 컴파일러 지원과 자동 데이터 정규화를 통해 React 클라이언트 개발을 쉽고 즐겁게 만듭니다. **GraphQL 도입은 프론트엔드 개발자가 주도하여 사용자 경험을 개선하고 더 나은 데이터 일관성을 제공**할 수 있습니다.

발표의 핵심은 기술적인 해결책보다는 **'기술보다 관점이 더 중요하다'**는 메시지입니다. 올바른 답변을 기억하고 연습하는 것도 중요하지만, 문제를 정확히 인식하고 스스로 질문을 던지는 것이 더욱 중요합니다. 코드와 컴포넌트를 분석하는 방식을 개선하고, 새로운 요구사항에 대한 반응과 코드 설계를 깊이 들여다보는 관점을 가질 것을 강조합니다.

발표자가 리액트 컴포넌트의 의존성을 설명하기 위해 케이크에 비유한 이유는 무엇이며, 이 비유가 컴포넌트 의존성 이해에 어떻게 도움이 되는지 설명해 주세요.

리액트 컴포넌트의 네 가지 의존성(스타일, 커스텀 로직, 글로벌 상태, 리모트 데이터 스키마) 중 발표자가 '리모트 데이터 스키마'를 가장 중요하게 강조한 이유는 무엇인가요?

발표자가 제시한 '함께 모아두기(Co-locate)' 원칙에 따라 스타일과 로직을 컴포넌트 내부에 배치하는 것이 왜 좋다고 설명하며, 'CSS-in-JS'를 예시로 든 이유는 무엇인가요?

컴포넌트 의존성을 느슨하게 만들고 재사용성을 높이기 위해 '글로벌 ID(Global ID)'와 'GOI(Global Object Identification)'가 어떤 역할을 하는지 구체적으로 설명해 주세요.

발표자가 컴포넌트를 분리하거나 재사용할지 결정할 때 '모델 기반으로 컴포넌트를 분리하라'는 원칙을 제시한 이유는 무엇이며, 이는 유지 관리 용이성과 어떻게 연결되는지 설명해 주세요.

안녕하세요. 올해 FEConf에서 컴포넌트 다시 생각하기라는 주제로 발표를 준비한 원지혁입니다. 아마 프론트엔드 개발자라면 어떤 것을 작성하고 어떻게 컴포넌트를 분리해야 할지 고민해 보셨을 텐데요.

이번 발표를 통해서 컴포넌트에 대한 관점을 한 단계 더 높일 수 있을 거라고 생각합니다.

발표 시작하겠습니다. 발표를 시작할 원지혁입니다.

저는 당근마켓 Thirdparty 팀에서 소프트웨어 엔지니어로 일하고 있고요. GraphQL 코리아 오거나이저로도 활동하고 있고, 클라이언트부터 백엔드까지 풀스택 개발자로 제품을 개발하고 있습니다.

먼저 컴포넌트에 대해서 함께 알아보겠습니다.

리액트 컴포넌트를 만들기 위해서 필요한 것과 유지보수를 막는 재료는 무엇이 있을지 함께 살펴보겠습니다.

저는 지난 주말에 서울 근교에 시간을 보냈는데요. 아주 예쁜 디저트 카페에 가서 딸기가 올라간 하얀 생크림 케이크를 팔고 있었습니다.

이런 케이크를 만들기 위해서는 무엇이 필요할까요? 저는 빵에 대해서 잘 모르지만, 밀가루, 설탕, 계란은 반드시 필요할 것 같습니다.

즉, 케이크를 만들기 위해서는 밀가루, 설탕, 계란 세 가지 재료가 반드시 필요합니다.

다시 말해서 케이크는 밀가루, 설탕, 계란에 의존적입니다.

이것을 다른 표현으로 나타내면 케이크는 밀가루, 설탕, 계란의 의존성을 가지고 있다고 표현할 수 있습니다.

저희는 의존성이라는 말을 많이 사용하는데요. 반대로 리액트 컴포넌트의 의존성은 무엇이 있을까요? 이와 마찬가지로 또 다른 표현으로 설명해 보겠습니다.

리액트 컴포넌트를 만들기 위해서는 무엇이 필요할까요? 다들 아시다시피 리액트 컴포넌트는 props와 hooks를 통해서 필요한 것들을 전달받을 수 있습니다.

이것은 리액트 컴포넌트의 의존성의 기능적인 분류라고 볼 수 있습니다. 그렇다면 props, hooks, import를 통해서 전달하는 의존성의 특징은 무엇이 있을까요?

props, hooks, import를 통해서 전달하는 것들인데요. 먼저 스타일이 있습니다. 다들 아시다시피 스타일은 CSS를 의미합니다.

대부분 CSS나 SCSS 파일을 외부 파일에 작성한 다음에 컴포넌트로 가져올 것입니다.

따라서 스타일은 컴포넌트의 의존성입니다. 두 번째는 컴포넌트에서 사용되는 특정 커스텀 로직입니다. UI를 조작하거나 리액트 컴포넌트에 의도된 side effect를 주기 위해서 특정 액션을 수행하는 데 사용됩니다.

일반적으로 커스텀 훅 형태로 작성됩니다. 세 번째는 글로벌 상태입니다.

글로벌 스테이트는 사용자 액션에 의해서 발생하는 클라이언트의 상태를 말합니다. 보통 로그인 정보라든지 전체 메뉴를 열고 닫는다든지, URI의 표현이라든지 이런 것들이 포함이 되고요. 마지막 의존성은 리모트 데이터 스키마입니다.

발표 준비하면서 고민을 많이 했는데, 쉽게 바꾸는 것보다 있는 그대로 표현하는 게 좋겠다 싶어가지고.

그대로 적었습니다. 리모트 데이터 스키마는 리모트, 즉 API 서버에서 내려오는 데이터를 의미하고요.

스키마라는 말은 데이터의 그릇을 의미합니다. API 서버에서 보내주는 JSON 데이터의 내용과 형태라고 생각하시면 좋을 것 같습니다.

제 생각에는 리액트 컴포넌트의 의존성의 특징적인 분류는 네 가지 정도가 있습니다.

리액트 컴포넌트의 의존성 중에서요. 이 의존성들 중에서 좀 더 눈여겨봐야 될 만한 것이 있는데요. 바로 리모트 데이터 스키마입니다. 페이스북에서 만든 GraphQL 클라이언트 중에 릴레이라는 문서에 이런 문구가 있습니다.

함께 읽어보겠습니다. 대다수의 제품은 하나의 특정한 동작을 원한다고 합니다.

로딩 인디케이터를 표시하는 동안 필요한 모든 데이터를 가져온 다음 데이터가 사용 가능할 때 전체 뷰를 렌더링한다는 것이죠.

아마, 이게 조금은 이해하기 어려우실 것 같아서 제가 제품 영상을 두 개 준비했는데요.

한번 보시겠습니다. 왼쪽은 로딩 상태가 각 컴포넌트에 위치해 있고 로딩될 때마다 뭔가 뚝뚝 떨어지는 느낌이 듭니다.

오른쪽은 로딩 상태가 끝나면 모든 컴포넌트가 준비가 돼서 한 번에 뿅 하고 나타나서 떠오르는 느낌이 듭니다.

여러분은 둘 중에 어떤 제품이 더 마음에 드시나요? 아마 여러분 모두 오른쪽을 원하실 거라고 생각합니다. 이제 저희가 아까 얘기했던 케이크 얘기를 다시 한번 해보겠습니다.

케이크에 딸기를 한 번 더 올려보겠습니다. 그런데 케이크에 딸기를 올리기 위해서 저는 딸기만 있으면 될 줄 알았는데, 추가적으로 휘핑크림이 필요하다는 것을 알게 되었습니다.

즉, 딸기 케이크는 나도 모르는 사이에 휘핑크림에 대한 추가적인 의존성이 생긴다는 의미입니다.

딸기 케이크의 숨겨진 의존성에 휘핑크림이 있다는 뜻이죠.

이제 저희가 리액트 컴포넌트에 새로운 정보를 추가하고 싶다고 가정을 해보겠습니다. 그러면 새로운 정보를 추가하기 위해서는 정보를 받기 위한 새로운 Props를 정의하겠죠.

여기서 컴포넌트는 새로운 정보뿐만 아니라 다른 수정 사항도 필요로 하게 됩니다.

이것을 리액트 컴포넌트의 숨겨진 의존성으로 표현하고 싶습니다. 이제 시나리오를 살펴보겠습니다.

예를 들어, 일반 게시판 모델에 새로운 정보를 추가하는 상황을 가정해 보겠습니다. 이제 중요한 점을 말씀드리겠습니다.

앞서 보여드린 로딩을 표현하면서, 모든 데이터가 로드되는 시점에 맞춰 전체 페이지를 표시하는 액션을 생성한다고 가정해 보겠습니다.

먼저 Article 컴포넌트의 Props를 수정하여 새로운 정보를 받도록 하겠습니다. 다음으로 Article 컴포넌트의 렌더링 부분을 수정하겠습니다.

그리고 포스트 목록에서 props를 편집하고, 루트 컴포넌트의 useEffect Hook을 편집하겠습니다.

따라서 새로운 정보를 표현하기 위해서는 정보뿐만 아니라 루트 컴포넌트와 중간 컴포넌트들의 변환이 불가피합니다.

따라서 이는 원격 데이터 스키마와의 숨겨진 의존성이 됩니다.

props drilling을 피하기 위해 데이터 저장소를 따로 설정하더라도, 페이지 기반 라우팅을 사용하는 경우 결국 루트 컴포넌트에 의존하게 됩니다.

분석한 리액트 컴포넌트 전체를 살펴보겠습니다. 이제 이러한 의존성을 하나씩 정렬하는 방법을 살펴보겠습니다.

첫 번째는 함께 모아두는 것입니다. 이를 Co-locate, Co-location이라고 합니다.

첫 번째 리팩토링 원칙을 소개하고 싶습니다. 비슷한 관심사가 있다면 가까이 두십시오. 무언가를 편집하는 동안 파일이 서로 멀어지면 집중력이 흐트러지기 쉽습니다.

따라서 비슷한 관심사가 있다면 같은 파일이나 바로 옆에 두는 것이 좋습니다.

앞서 살펴본 의존성 모델로 돌아가서, 네 가지 의존성 중에서 어떤 것을 함께 모아두는 것이 가장 쉬울까요?

우선, 글로벌 상태는 여러 컴포넌트에서 사용되므로 함께 유지하기는 어려울 것 같습니다.

스타일과 로직은 함께 두기 쉬울 것 같습니다. 따라서 다음과 같이 컴포넌트에 내장되도록 변경해 보겠습니다.

일반적으로 CSS-in-JS를 솔루션으로 사용합니다. 이 작성 방법은 실제로 공동 배치로 볼 수 있습니다.

코드를 살펴보겠습니다. 다음과 같이 컴포넌트 파일 내부에 로직과 스타일을 함께 배치했습니다.

이제 특정 부분을 편집해야 할 때 스타일과 로직을 편집해야 하는 경우 여러 파일을 왔다 갔다 할 필요 없이 함께 편집할 수 있습니다.

하나의 컴포넌트 크기가 너무 크면 걱정될 수도 있습니다.

그럴 경우에는 파일을 상하위 폴더로 나누는 것이 아니라, 동일한 폴더 내에서 파일별로 분리하는 것을 추천합니다.

다음으로는 리모트 데이터 스키마를 함께 묶어야 하는데요. API 서버에서 리모트 데이터 스키마가 어떻게 내려오는지 간략하게 살펴보면 다음과 같이 루트 컴포넌트와 다른 컴포넌트를 거쳐서 제 컴포넌트로 오게 됩니다.

여기서 만약에 Props를 통해서 데이터 스키마를 받게 되면 루트 컴포넌트와 강한 의존성을 가지게 되는데요. 이 부분을 개선해서 데이터를 가져올 수 있게 하고, ID는 Props를 통해서, 그리고 데이터 스토어를 통해서 가져올 수 있게 하면 의존성을 끊을 수 있습니다.

다음과 같은 코드가 있다고 가정을 해보겠습니다. 보시는 바와 같이 TypeScript 문법이 JavaScript만 사용하셨던 분들에게는 조금 어색할 수도 있습니다.

다음과 같이 Props에서 `article`이라는 필드에 특정 게시글에 대한 정보를 받고 있습니다.

이 컴포넌트를 함께 개선해 볼 텐데요. 그러면 다음과 같이 Props로는 게시글 ID에 해당하는 스트링 값만 받고 컴포넌트 내부에서는 특정 훅, 이 경우에는 `useArticle` 훅을 통해서 데이터를 받도록 구현할 수 있습니다.

이렇게 함으로써 다른 컴포넌트와의 의존성이 확실히 약해진 것을 확인할 수 있습니다.

그런데 어떻게 구현해야 할지 궁금하실 수도 있을 것 같습니다.

이를 위해서 두 번째 리팩토링 원칙을 소개해 드리고 싶습니다. 두 번째 원칙은 ID 기반으로 데이터를 구성하라는 것입니다.

API 응답이 다음과 같이 온다고 가정을 해보겠습니다. 여기서는 ID를 기반으로 특정 객체에 접근하기가 어려워 보입니다.

그런데 API 응답을 다음과 같이 구성하면 어떻게 될까요? 모델 이름과 ID만으로 특정 데이터를 추출하는 것이 가능해집니다.

이것을 Normalization이라고 부릅니다. Normalization을 도와줄 수 있는 라이브러리가 있는데요. Normalizr라는 패키지가 있습니다.

관심 있으시면 살펴보시면 좋을 것 같습니다. 그러면 이 Normalization된 데이터를 가지고 데이터 스토어에서 특정 객체를 쉽게 가져올 수 있게 됩니다.

이것은 또 다른 숨겨진 의존성을 만드는데요. 모델을 최상단에서 정확히 알고 있어야 한다는 점입니다.

느슨한 의존성을 만들기 위한 컨셉을 하나 소개해 드리고 싶은데요. 바로 글로벌 ID입니다. 글로벌 ID는 특정 객체를 식별하기 위해서 모델 이름을 별도로 전달할 필요 없이 ID 값만으로 특정 데이터를 유일하게 식별할 수 있도록 하는 시스템입니다.

보통 모델 이름과 ID 값을 문자열로 연결해서 만들게 됩니다.

경우에 따라 Base64 인코딩 및 디코딩을 할 수도 있습니다. 그럼 다시 예제로 돌아가 보겠습니다.

다시 주의 깊게 살펴보면, `Import`를 통해 가져온 `useArticle`이라는 Hook의 이름이 보일 텐데, 이는 컴포넌트가 Article의 정보가 필요한 컴포넌트 외부에서도 주입되고 있음을 확인할 수 있습니다.

이것을 다음과 같이 글로벌 ID를 통해 데이터를 가져오는 `useNode` 훅으로 대체하면, 함께 사용할 모델 정보를 컴포넌트 내부에 넣을 수 있습니다.

한 걸음 더 나아가 GOI라고도 하는 Global Object Identification을 소개하고자 합니다.

이는 글로벌 ID를 통해 API 서버에 요청할 때 객체를 가져올 수 있게 해주는 API입니다.

서버 측에서 API가 제공되면 모든 컨텍스트에서 객체를 호출할 수 있습니다.

이러한 GOI API는 다양한 방식으로 사용될 수 있습니다. 첫째, 특정 필드가 데이터 저장소에 존재하지 않을 때 추가 데이터 가져오기를 자동화할 수 있습니다.

이를 위해 컴포넌트가 어떤 필드를 사용하고 있는지 표현해야 합니다. 다음 형식 코드로 사용할 필드를 표현할 수 있습니다.

그렇다면 최종 데이터 흐름은 어떻게 될까요? 먼저 루트 컴포넌트에서 검색된 데이터를 정규화하여 데이터 저장소에 넣습니다.

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

스크립트