SWR 라이브러리 분석: 테스트 코드 및 캐시 관리

좋은 코드를 이해하려면 테스트 코드와 주석을 통해 SWR과 같은 오픈 소스 라이브러리를 분석하여 효과적으로 활용하고 구현해야 합니다.

### SWR 라이브러리 분석: 핵심 개념 및 테스트 코드 이해
* 📚 SWR은 데이터와 로딩 상태를 효과적으로 관리하는 오픈소스 라이브러리로, 깔끔하고 멋진 구현으로 유명하며 **Mutable, Infinite, Mutate**와 같은 인기 있는 라이브러리에서 사용되고 있습니다.
* 라이브러리를 분석할 때는 코드의 예상 동작과 처리되는 사례를 이해하고 **추가 테스트 코드를 작성할 때 참고**할 수 있도록 **테스트 코드부터 시작**하는 것이 좋습니다.
* 💻 프론트엔드에서 E2E 테스트를 하면 사용자 관점에서 포괄적인 테스트가 가능하지만 계획과 디자인이 자주 변경되는 환경에서는 **서버 측 렌더링과 같이 변경되지 않는 핵심 로직을 테스트**하는 데 집중하는 것이 더 비용 효율적일 수 있습니다.
* 🔑 SWR 테스트 코드를 살펴보면 **키를 테스트하는 방법, `mutate` 함수를 사용하여 데이터를 설정하는 방법, `RenderWithConfig`를 사용하여 테스트 코드를 작성하는 방법**을 배울 수 있습니다.
* 💬 SWR 라이브러리는 동일한 캐시 키를 가진 중첩된 컴포넌트가 **다른 값을 가질 수 있음**을 나타내는 주석과 같이 코드를 한 눈에 이해하는 데 도움이 되는 잘 작성된 주석이 돋보입니다.
* 🔄 SWR은 전역 상태가 없을 때 키-값 쌍을 **'맵' 객체에 저장하는 '캐시' 객체**를 생성하여 캐시 데이터를 관리하고 사용하며, 메모리 수집을 쉽게 하기 위해 **'위크맵'**을 사용합니다.
* 🌐 SWR의 `**useIsomorphicLayoutEffect**` 변수 이름이 흥미로운데, 이는 페인트되기 전에 실행되지만 서버 측에서는 React Concurrent 모드로 인해 다르게 동작하는 이펙트를 가리킵니다.
* 📖 라이브러리를 분석할 때는 **좋은 코드 관행에 대해 배우고, 라이브러리에 대한 이해를 깊게** 하고, 라이브러리를 사용할 때 **보다 상세하고 구체적인 코드**를 작성하는 것이 좋습니다.

Hello, one of the ways to write good code is to look at a lot of good code. When you ask what good code is, there are things like open-source libraries. I went in to see what's good about open source, but I didn't know how to look at it, so I had a lot of concerns. I thought it would be nice to share how to view it together. The open-source library I brought is SWR. It's a library that manages data and handles loading states well. There's also React Query and Redux Toolkit. SWR is really clean and nice. So, this is a library that Mutable, Infinite, and Mutate actually use. If you go in, there's also JSON as a package. I understood it as a multi-package structure with each package having dependencies.

There are internals and cores. Probably, they will have internal business logic. The core has US swr. This US swr is a method that users directly use from the outside based on the swr criteria. Looking at the internal, there is uts and various functions. Usually, the underscore signifies private. I think they have distinguished the internal business logic folder from a user's perspective. When analyzing libraries, if there are test codes, I really recommend starting with the test codes. Understanding the expected behavior of the code and quickly grasping how it actually works can be done. Not only that, you can know what cases are being handled, so when you write separate test codes, you can understand concepts like Oh, I can test this again. I really like that. So, I will show you the test code once. For now, I see that there are two tests.

It was really fascinating, you know, how well it draws when you press a button to receive this kind of data, and whether the button is disabled properly depending on the situation. From testing the overall UI to receiving responses from the server, you can comprehensively test. I always have doubts about whether tweet testing is really necessary on the frontend. You can know once you try it, but I was curious if I should organize that. When I looked at the two-day test, there was a site. So, on the site, there are apps, libraries, and pages, and I saw that a simple site was created for mocking. The important thing is to check the tests. I used Playwright, which is a library that can do tweet tests just like Cypress, but I heard it's made by Microsoft and fits well with VS Code. It's very short, there are only two.

I am testing two things, Basic Essence and Arirang Pearl Hydrate. When we say base SSR, it means testing if server-side rendering works well. The rock test is to see if it looks good on the page. Similarly, I tested if hydration occurs partially, in a simple way, using the rock test. In frontend, E2E testing allows comprehensive testing from the user's perspective, which is useful. However, in an environment where planning and design change frequently, maintenance costs seem high. When the design changes, you need to reflect the design, and it feels like testing has doubled. It seems cost-effective to focus on judging only core logic that does not change, like server-side rendering. I realized that I only tested to a certain extent and that caching could be done.

I was curious, so I looked it up for the first time, so it comes out right here. I'm going to look at the text of the Usw branch. You just need to see what they tested based on this. It says here that it's a cache update cache. If it's a cache, you need to update it. Oh, it says here issue-payable 2 update cache value. When mutated, you need to see the cached value accurately. If you're curious about what that means, you should look into it. They are creating keys with create cache, making a component called page, putting it in the left config, and putting the cached value here. When you do that, it looks good. Then you execute the mutate here. So, when you put in the mutated value, the mutated value appears on the next screen. This mutation is.

In SWR, there is a function that allows you to set data. When you execute the mutate function, you can consider it as testing whether a new snapshot is taken. If you are curious about what this RenderWithConfig is, you can just go in and take a look. RenderWithConfig is different from the underscore RenderConfig; it puts in a different configured element and provider. If you wonder what this is, it's right here. It's about rendering. This render is a random method provided by the React library. It allows you to render React components into the DOM. So, I inserted a React component here and through rendering, it was drawn onto the DOM. You can also learn how to write test code. What was really great about SWR is that the comments were written very kindly. So, when you look at it, it's nested.

It is written from the component that same cash can get different value. Nested components with the same cache key can have different values. I created a component called Foo and a component called Page. The Foo component is a function that receives data by putting a key created by the create key function and returns it as it is. The Page component uses the same key to spread and display data, setting the value of the SWR config data to 2. After rendering this page, the getText function should return 1 something 2. When passing the data to the page, it was passed as 1, so that's why 1 is displayed here. Similarly, even though the same key value was used for Foo, it should show differently because the data was passed as 2. Through this, I tested that simply distinguishing uniqueness by the key value is not enough.

You can see up to the components, and you can know when you write the code that you don't have to make an effort to change the key value, as it will come out correctly because it is a different component. So, you can see how many you have now. You know how to write test code, right? You know how the key works in SWR. You can understand how to utilize comments to understand how it works at once. That's why there's no reason not to look at the test code. Oh, I think I would be curious about how the cache is created with this much information. When you go internal, there will be a cache, right? Exactly. So, let's take a look at the cache.ts. There's a mini-cache. It seems like it will trigger something. When there is no global state in SWR, it creates an object called ValidatorEvent, creates Tate, creates an object called Subscription, and also creates an object called subscribe, receiving a callback.

It feels like registering something, creating new objects. The cache now saves the data I brought as a key and value in the ping object, so it has a principle of retrieving the value if it exists later. When there is no SWR global state, these objects are created. If you look here, it's a WeakMap. You might wonder what WeakMap is, you can google it. Instead of a map, why is it reachable or likely to be used in the future, the values are maintained in memory. Therefore, memory leaks sometimes occur, and there are many discussions about issues related to collections. It doesn't seem like WeakMap will solve the problem, right? It's like a weak wrap, not a map. When using a WeakMap, objects used as keys become targets of garbage collection. So, WeakMap is a bit better than a map.

Can it be collected? So, when do you use this? If you think about caching, having it is nice, but it's not really a problem if you don't have it functionally. In fact, there are more issues when caching is not done. Memory gets full and such things happen. So, in order to make it easier to collect, we use weak maps. By creating a state with this, you can manage cache data. By analyzing it this way, you can roughly understand how SWR manages and uses cache. In this way, you can just look at one by one the concepts you want to know or the core concepts. What was interesting was that they used the useMemo layout effect. Isomorphic means that the nature or shape of things is the same.

It's fascinating to use such variable names. When you try it, it runs the news layer effect instead of the server. I wonder why it's distinguished as a server. When I asked, the comments were well written. In React Concurrently, it says server for maintenance. It seems like React is giving a warning. I was curious about what the effect is. So, I just typed it. When you try React News Layer Effect, it appears right away. It is said that effects are executed after components are rendered and painted. The News Layout Effect is something that runs before being painted. It seems like it wanted to draw something before being painted. However, on the server-side, it spits out errors, so I could see that branching was handled this way. In conclusion, it's about copying. Since SWR has well-written comments, it works well.

You might think it's not, but you can just search for it. It comes out right here. In the news layout effect, it says nothing on the ser. So, it means that something is not working properly on the server. Learning about good code, increasing understanding of this library, and being able to write more detailed and specific when using it. These are small tips to share. I'll finish the video. When I was analyzing the library earlier, something came up. It's a browser extension called GitLens. Here, you can see who committed, when they committed, and what the committed files are about. By clicking, you can directly connect to GitHub, check it right away, and there are release notes. You can immediately see what has been changed. Just by going into GitHub, you can greatly enhance your understanding of this library.

If you want to leave feedback or raise an issue, there is a label called Good First Issue. This label literally means a good issue. You might wonder how to leave feedback well when you want to raise an issue. Searching for good issues with this kind of tag is also a way. For big libraries like React, sometimes everything is documented. Here, even the contribution guide is kindly provided. Just by reading the rhythm, you can understand. When you see how the rhythm is written in personal projects, you can create more rich and good library code. After finishing the analysis on a large scale, take a look at the test code, and then proceed step by step with what you want to know. I wanted to say that you can enjoy analyzing libraries by doing this. If you are interested in knowing my other study methods, what would you like to know?

I would appreciate it if you could write down what you want to know in the comments. It would be great, and I will come back with even better videos next time. Goodbye.

오픈소스 볼 줄 모르면 꼭 봐야 할 구체적인 분석 방법 (Feat. SWR)

hyosunglim임효성

SWR 오픈 소스 라이브러리 분석하기

SWR은 깔끔하고 효율적인 오픈소스 라이브러리로 Mutable, Infinite, Mutate에서 사용됩니다.

내부 비즈니스 로직과 사용자 대면 코어가 있는 다중 패키지 구조로 되어 있습니다.

라이브러리의 테스트 코드는 UI 테스트 및 서버 응답을 포함하여 예상되는 동작과 기능을 이해하기 위한 훌륭한 출발점입니다.

Microsoft에서 만든 라이브러리인 Playwright는 UI 및 서버 응답 테스트에 중점을 두고 SWR 라이브러리에서 엔드투엔드 테스트에 사용됩니다.

베이직 에센스 및 아리랑 펄 하이드레이트 테스트

테스트에는 기본 SSR, 외관에 대한 암석 테스트, 부분 수화 테스트가 포함됩니다.

프론트엔드에서 E2E 테스트를 하면 포괄적인 사용자 관점의 테스트가 가능하지만 유지 관리 비용이 많이 들 수 있습니다.

서버 측 렌더링과 같은 핵심 로직에 집중하는 것이 더 비용 효율적일 수 있습니다.

테스트에는 캐시 업데이트와 SWR에서 새 스냅샷을 테스트하기 위한 변경 기능을 사용하는 것도 포함됩니다.

RenderWithConfig와 RenderConfig는 React 컴포넌트 렌더링에 사용되며, 테스트 코드 작성에 대한 인사이트를 제공합니다.

SWR의 유용한 주석과 중첩 구조는 테스트 프로세스에서 강조 표시됩니다.

SWR의 캐싱 및 주요 값의 복잡성

Foo 및 Page 컴포넌트에서 테스트한 것처럼 동일한 캐시 키를 가진 컴포넌트는 서로 다른 값을 가질 수 있습니다.

서로 다른 컴포넌트가 여전히 다른 데이터를 표시할 수 있으므로 키 값만으로는 SWR의 고유성을 보장하기에 충분하지 않습니다.

SWR 캐시는 키-값 쌍을 유지하기 위해 WeakMap을 사용하며, 이는 메모리 누수로 이어질 수 있어 많은 논의의 대상이 되어 왔습니다.

SWR에서 효율적인 캐싱을 위한 약한 맵 사용

약한 맵은 SWR에서 캐시 데이터를 쉽게 수집하고 관리하기 위해 사용됩니다.

SWR은 사용 메모와 레이아웃 효과를 활용하며, 뉴스 레이아웃 효과는 페인트되기 전에 실행되고 서버 측은 유지 관리를 위해 구분됩니다.

또한 라이브러리에는 잘 작성된 주석이 있으며, GitLens 브라우저 확장 프로그램은 라이브러리의 GitHub 활동에 대한 통찰력을 제공하여 이해를 높일 수 있습니다.

라이브러리 분석에서 피드백을 제공하고 문제를 제기하는 효과적인 방법

"좋은 첫 번째 이슈" 라벨을 사용하면 React와 같은 대규모 라이브러리에서 피드백 및 기여에 적합한 이슈를 찾는 데 도움이 될 수 있습니다.

문서와 기여 가이드의 리듬을 이해하면 고품질 라이브러리 코드를 만드는 데 도움이 될 수 있습니다.

테스트 코드를 분석하고 단계별로 진행하는 것은 라이브러리 분석을 즐기고 배울 수 있는 좋은 방법입니다.