Analyzing SWR Library: Test Codes and Cache Management

Understanding good code involves analyzing open-source libraries, like SWR, through test codes and comments for effective utilization and implementation.

### SWR Library Analysis: Understanding Core Concepts and Test Code
* 📚 SWR is an open-source library that effectively manages data and loading states, known for its **clean and nice implementation**, and is used by popular libraries like **Mutable, Infinite, and Mutate**.
* When analyzing libraries, it is highly recommended to start with the test codes, as they help **understand the expected behavior of the code**, the cases being handled, and serve as a **reference for writing additional test codes**.
* 💻 E2E testing in the frontend allows comprehensive testing from the user's perspective, but in environments where planning and design change frequently, it may be more cost-effective to focus on testing **core logic that does not change**, such as server-side rendering.
* 🔑 By looking at the SWR test code, it can be learned **how to test the key**, **how to use the `mutate` function to set data**, and **how to write test codes using `RenderWithConfig`**.
* 💬 The SWR library stands out for its well-written comments, which help understand the code at a glance, such as the comment indicating that **nested components with the same cache key can have different values**.
* 🔄 SWR manages and uses cache data by creating a `cache` object that saves key-value pairs in a `map` object when there is no global state, and using **`WeakMap` to make it easier to collect memory**.
* 🌐 The `useIsomorphicLayoutEffect` variable name in SWR is interesting, and it refers to an effect that runs before being painted, but behaves differently on the server side due to **React Concurrent mode**.
* 📖 When analyzing libraries, it is beneficial to **learn about good code practices**, **deepen the understanding of the library**, and **write more detailed and specific code** when using it.

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 is a clean and efficient open-source library used by Mutable, Infinite, and Mutate.

It has a multi-package structure with internal business logic and a user-facing core.

The library's test codes are a fascinating starting point for understanding its expected behavior and functionality, including UI testing and server responses.

Playwright, a Microsoft-made library, is used for end-to-end testing in the SWR library, with a focus on UI and server response testing.

Testing Basic Essence and Arirang Pearl Hydrate

Testing includes base SSR, rock test for appearance, and partial hydration testing.

E2E testing in the frontend allows comprehensive user perspective testing but can lead to high maintenance costs.

Focusing on core logic like server-side rendering may be more cost-effective.

The testing also involves cache updates and using the mutate function to test new snapshots in SWR.

RenderWithConfig and RenderConfig are used for rendering React components, providing insight into writing test code.

SWR's helpful comments and nested structure are highlighted in the testing process.

The Complexity of Caching and Key Values in SWR

Components with the same cache key can have different values, as tested with the Foo and Page components.

The key value alone is not sufficient to ensure uniqueness in SWR, as different components can still display different data.

The SWR cache uses a WeakMap to maintain key-value pairs, which can lead to memory leaks and has been the subject of much discussion.

Using Weak Maps for Efficient Caching in SWR

Weak maps are used to facilitate easier collection and management of cache data in SWR.

SWR utilizes useMemo and layout effect, with the news layout effect running before being painted, and the server-side being distinguished for maintenance.

The library also features well-written comments, and the GitLens browser extension can enhance understanding by providing insights into the library's GitHub activity.

Effective Ways to Provide Feedback and Raise Issues in Library Analysis

Using the "Good First Issue" label can help in finding suitable issues for feedback and contribution in big libraries like React.

Understanding the rhythm of documentation and contribution guides can help in creating high-quality library code.

Analyzing test code and proceeding step by step is a great way to enjoy and learn from library analysis.