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)

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