안녕하세요. 좋은 코드를 작성하는 방법 중에 하나로 좋은 코드를 많이 보라는 얘기를 하거든요.

좋은 코드는 뭐가 있냐 했을 때 오픈 소스 라이브러리 같은 게 있거든요.

오픈 소스 뭐 좋다고 해서 들어가 봤는데 어떻게 봐야 될지도 모르겠고 좀 고민이 많이 됐었단 말이에요.

어떻게 보는지 같이 공유하면 좋을 것 같아 가지고 가져온 오픈 소스 라이브러리는 SWR이거든요.

데이터를 관리하고 로딩 상태를 잘 처리해 주는 라이브러리에요.

렉토컬도 있고 리덕스 툴킷 같은 것도 있어요.

SWR이 진짜 후드 너무 깔끔하고 너무 좋더라고요.

그래서 이건데 뮤터블이랑 인피니트랑 뮤테이트가 실질적으로 사용하는 라이브러리에요.

들어가 보면은 패키지처럼 제이슨이 또 있어요.

각 팔당 패키지스를 가지고 있는 멀티 패키지 구조구나 정도로 저는 이해를 했었고요.

인터널이랑 코어가 있죠. 아마 얘네가 내부 비즈니스 로직을 가질 것 같아요.

코어에는 useSWR이 있어요. 이 useSWR도 SWR 기준으로 외부에서 직접 사용자들이 사용하는 메소드거든요.

그리고 인터널을 보면은 UTS가 있고요.

여러가지 함수들이 쫙 있어요. 보통 언더바가 프라이빗을 의미하잖아요.

사용자 관점을 기준으로 그 내부 비즈니스 로직 폴더를 구별해 놓은 거 아닌가 싶더라고요.

라이브러리 분석을 할 때 만약 테스트 코드가 있다면 테스트 코드부터 보는 거를 진짜 추천드려요.

코드의 예상되는 동작을 이해하고 실제로 어떻게 동작하는지 빠르게 파악할 수 있거든요.

그뿐만 아니라 어떤 예외 케이스를 다루고 있는지 알 수 있어 가지고 내가 따로 테스트 코드를 짠다고 했을 때 '아, 이런 거를' 또 테스트로 짤 수 있구나'라는 개념들을 알 수 있어서 저는 너무 좋더라고요.

그래서 테스트 코드를 한번 같이 까보도록 할게요.

일단 저는 E2E 테스트 있는 게 진짜 신기했거든요.

어떤 버튼을 눌렀을 때 이러한 데이터를 받아오는데 잘 그려지는지, 버튼이 상황에 따라서 잘 디세이블도 되는지, 이런 전반적인 UI부터 서버에서 받는 응답값까지 종합적으로 테스트를 할 수 있는데, 프론트엔드에서 E2E 테스트가 과연 필요할까에 대한 의문을 항상 가지고 있긴 하거든요.

내가 한번 눌러보면 알 수 있는 건데, 그거를 굳이 짜야 될까 신기해서 까봤어요.

E2E 테스트 보면은 이 사이트라는 게 있어요.

그래서 사이트에서 앱이랑 뭐 라이브러리랑 페이지스 있는 거 보니까 간단한 모킹 할 수 있는 그런 사이트를 만들어 놓은 거고 중요한 건 E2E 테스트를 봐야겠죠.

플레이 라이트를 썼더라고요. 사이프레스랑 똑같이 E2E 테스트 할 수 있는 라이브러리인데 마이크로소프트에서 만들어 가지고 조금 더 VS 코드랑 잘 어울린다고 들었어요.

되게 짧아요. 두 개밖에 없더라고요. 베이직 에센스 아리랑 펄펄 하이드레이트 이 두 가지를 테스트를 하고 있어요.

베이스 SSR이라고 하면은 서버사이드 렌더링이 잘 되는지를 테스트한 거겠죠.

갯바위 테스트로 페이지에서 잘 보이냐 그거 테스트한 거고요.

부분적으로 하이드레이트가 되는지 마찬가지로 갯바위 텍스트로 이렇게 심플하게 테스트를 해놨더라고요.

프론트엔드에서 이트리 테스트가 사용자 관점에서 종합적으로 테스트를 할 수 있어서 유용은 한데 빠르게 기획이랑 디자인이 많이 바뀌는 환경에서는 유지보수 비용이 많이 들 것 같더라고요.

디자인이 바뀌었어요. 그래서 디자인을 반영을 해야 되는데 테스트까지 두 배로 늘어난 느낌이잖아요.

서버사이드 렌더링 같이 변하지 않는 핵심 로직만 좀 판단하는게 그나마 가성비 있지 않나라고 생각이 들더라고요.

이 치즈스는 이 정도로만 테스트를 했구나.

보고 캐시가 되게 궁금해서 처음에 까봤었던 거거든요.

그래서 여기 바로 나오죠. usw열 캐시점 텍스트를 볼게요. 이 슬 기준으로 얘네가 뭘 테스트했는지를 보면 돼요.

이슈 피에이블 2 업데이트 캐시라고 나와 있어요.

캐시를 업데이트 해야 된다. 아, 캐시라면 업데이트해야지. 이슈 페이 커리 뮤테이터 캐시 밸류라고 있어요.

뮤테이트 되었을 때 정확히 캐시된 밸류를 봐야 된다.

무슨 뜻이지라고 궁금해진다면 거기 들여다보면 돼요.

크레이트 캐시로 키를 만들고 있죠. 페이지라는 컴포넌트를 만들어서 원다윗 컨피그에 넣어놓고 캐시드 밸류를 여기다 넣어 놨잖아요.

그 다음에 뮤테이트를 여기서 실행을 해요. 그래서 뮤테이치즈 밸류를 넣었을 때 다음 스크린에서는 뮤테이티드 밸류가 나온다는 거예요.

이 뮤테이트가 그 SWR에서 데이터 세팅할 수 있는 함수거든요.

뮤테이트를 실행하면 새롭게 백칭이 되는가를 테스트한 거라고 볼 수 있어요.

이 렌더위 컴피가가 뭔지 궁금하면은 그냥 들어가서 까보면 돼요.

렌더위 컴피그는 이 언더바 렌더위 컨피그의 엘리먼트랑 프로바이더랑 다른 컨피그를 넣는데 얘는 뭐지라고 하면은 여기 바로 있네요.

이 렌더는 뭐냐면 리액트 켓 라이브러리에서 제공해 주는 렌더 메서드인 거예요.

리액트 JXX를 돔에다가 그릴 수 있는 메서드를 제공하거든요.

아, 그래서 리액트 컴포넌트를 여기다 넣었고 렌더를 통해서 도매 그리게 됐구나를 파악할 수 있어요.

테스트 코드를 짜는 방법도 아는 거예요.

SWR이 진짜 분석하기 또 좋았던게 주석을 정말 친절하게 써놨거든요.

그래서 보면은 네스티드 컴포넌트부터 same cash can get different value라고 적혀 있어요.

같은 캐시 키를 가진 중첩된 컴포넌트들은 다른 밸류를 가질 수 있다는 거예요.

후라는 컴포넌트를 만들고 페이지라는 컴포넌트를 만들었는데, 이 후라는 컴포넌트는 크리에이트 키로 만든 키를 넣어서 데이터를 받아서 그걸 그대로 리턴하는 함수고요.

페이지라는 컴포넌트는 같은 키를 가지고 데이터를 뿌리고 SWR 컴피그의 데이터를 값을 2로 주고 있네요.

그리고 나서 이 페이지를 렌더를 해요.

그랬더니 이 겟 바이 텍스트가 어떻게 나와야 되냐면 1땡땡 2로 나와야 된다는 거예요.

페이지를 넣을 때 데이터를 1로 넘어갔죠.

그래서 여기서 1이 나오는 거고, 푸도 마찬가지로 같은 키 값을 썼지만 데이터를 2로 내려줬기 때문에 같은 키 값을 쓴 데이터여도 다르게 나와야 된다는 걸 테스트한 거예요.

아, 이걸 통해서 단순히 키 값으로만 고유함을 판별하는 게 아니라 컴포넌트까지도 보는구나를 알 수 있고 코드를 짤 때도 굳이 키 값을 바꾸려고 노력을 하지 않아도 다른 컴포넌트니까 바르게 나오겠구나를 알 수 있는 거죠.

지금 얻은 게 몇 개예요? 테스트 코드 짜는 방법 알았죠.

SWR에서 이 키 값을 어떻게 동작시키는지 알았죠? 주석을 어떻게 활용을 해야 어떻게 동작하는지 한 번에 알 수 있는 거예요.

그래서 테스트 코드 안 볼 이유 없는 거죠.

아, 저는 이 정도면은 캐시가 어떻게 만들어졌는지 좀 궁금할 것 같아요.

인터널 가면 캐시 있겠죠? 바로 있죠.

그래서 캐시점 TS를 한번 볼게요. 미니 캐시가 있어요. 뭔가 얘가 시작을 시킬 것 같아요.

SWR 글로벌 스테이트가 없을 때 이벤트 우리 밸리데이터라는 빈 객체를 만들고요.

스테이트도 만들고요. 서브스크립션이라는 빈 객체도 만들고요.

subscribe라는 얘도 만들어요. 콜백을 받아 가지고 등록시키는 얘 같아요.

뭔가 새로운 객체들을 막 만들어 내고 있거든요. 캐시가 이제 빈 객체에다가 키하고 밸류로 내가 가져왔던 데이터를 저장해서 나중에 그 값이 있으면은 가져오는 그런 원리를 갖고 있기 때문에 빈 객체를 만드네요.

SWR 글로벌 스테이트가 없을 때 이러한 객체들을 만든단 말이에요.

SWR 글로벌 스테이트는 여기 보면 위크 맵으로 되어 있는 거예요.

이 위크 맵은 뭐지라고 생각할 수도 있잖아요.

구글링 해보면 돼요. 맵이 아니라 왜 위크 맵이지?

컬렉션이 도달 가능하거나 추후 사용될 가능성이 있는 값을 메모리에 유지를 하거든요.

그렇다 보니까 메모리 누수가 가끔 일어나고 값이 컬렉션에 대한 문제다라고 하면서 막 얘기 나오는 것들도 되게 많아요.

문제를 뭔가 해결할게 위크 맵 같지 않아요? 맵인데 약한 맵 같잖아요. 위크 맵을 사용하면 키로 쓰인 객체가 가비지 컬렉션의 대상이 된다고 합니다.

그래서 맵보다는 위크 맵이 좀 더 잘 수거가 되나 보죠. 그럼 이걸 언제 쓰냐?

바로 캐싱 생각을 해보면 캐싱이라는 거는 있으면 좋고 없어도 기능상으로 사실 문제가 되진 않는단 말이에요.

오히려 캐싱을 수거 안 했을 때 문제가 더 많거든요.

메모리가 꽉 차고 막 그런 것들 있잖아요.

그래서 좀 더 수거 대상이 쉽게 되도록 위크 맵을 쓰는 거예요.

이걸로 저녁 상태를 만들어서 캐시 데이터를 관리하고 있구나를 알 수 있는 거예요.

이렇게까지 판단하면 SWR에서 캐시를 어떻게 관리하고 있고 어떻게 쓰고 있고를 얼추 파악한 거 같아요.

이런 식으로 자기가 알고 싶은 개념이나 아니면 핵심 개념들을 위주로 하나씩 그냥 까보면 되는 거예요.

재밌었던 게 유즈 아이소모픽 레이아웃 이펙트라는 걸 쓰더라고요.

아이소모픽이라는 게 사물의 성질 또는 모양이 같다는 뜻이거든요.

이런 변수명도 쓰는구나. 너무 신기한 거예요.

써보면 유지 이펙트를 실행하고 서버가 아니라면 유즈 레이어 이펙트를 실행한대요.

왜 서버로 구별해 놨지라고 했을 때 주석이 또 잘 써져 있어요.

리액트 커렌트리 저저 워딩 웬 유지는 서버라고 나와 있어요.

리액트에서 뭐 경고를 하고 있나 봐요.

'이펙트가 뭐지?'라는 궁금함이 들었어요. 그러면 그냥 쳤는데요.

리액트 useLayoutEffect 쳐보면 바로 나오죠. useEffect는 컴포넌트들이 렌더와 페인트된 후에 실행이 된다고 합니다.

useLayoutEffect는 렌더된 후 페인트 되기 전에 실행되는 거예요.

페인트 되기 전에 뭔가 그리고 싶었나 봐요.

근데 서버 단에서는 에러를 내뿜으니까 이렇게 분기 처리를 해놨구나를 알 수 있었어요.

결론은 카피다라는 거잖아요, SWR이.

주석을 잘 써놔서 하기 잘 되는 거 아니야라고 생각하실 수도 있는데 검색만 해봐도 돼요.

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

hyosunglim임효성

오픈 소스 라이브러리 분석 방법으로 SWR 라이브러리를 예시로 들어, 테스트 코드와 주석을 활용하여 코드의 동작 방식과 핵심 개념을 파악하는 방법을 설명합니다.

SWR 라이브러리의 캐시 관리 방식과 React의 useLayoutEffect 사용 이유를 분석하며, 깃 렌즈 확장 프로그램, 릴리즈 노트, 굿 퍼스트 이슈 라벨 등을 활용하여 라이브러리 이해도를 높이는 팁을 제공합니다.

라이브러리 분석을 통해 얻은 지식을 바탕으로 코드 작성 능력 향상과 라이브러리 기여 방법을 제시합니다.

🧐 오픈소스 라이브러리, 왜 봐야 할까요?

좋은 코드를 작성하는 방법 중 하나는 **좋은 코드를 많이 보는 것**이라고 합니다. 그 중에서도 오픈 소스 라이브러리는 훌륭한 학습 자료가 될 수 있습니다. SWR 라이브러리를 예시로, 오픈 소스를 어떻게 분석하고 활용할 수 있는지 알아봅니다.

📚 SWR 라이브러리 구조 파악하기

SWR은 데이터를 관리하고 로딩 상태를 처리하는 라이브러리입니다. **뮤터블, 인피니트, 뮤테이트** 등이 주요 기능으로 사용됩니다. 라이브러리 구조를 살펴보면, 멀티 패키지 구조로 구성되어 있으며, `internal`과 `core` 폴더로 나뉘어져 있습니다. `core`에는 사용자가 직접 사용하는 `useSWR`이 있고, `internal`에는 내부 비즈니스 로직 관련 함수들이 존재합니다.

🧪 테스트 코드, 어떻게 활용해야 할까요?

라이브러리 분석 시 **테스트 코드부터 보는 것을 추천**합니다. 테스트 코드를 통해 코드의 동작 방식과 예외 케이스를 빠르게 파악할 수 있습니다. E2E 테스트는 UI부터 서버 응답까지 종합적으로 테스트할 수 있지만, **잦은 기획 및 디자인 변경 시 유지보수 비용이 많이 들 수 있습니다**. 따라서, 서버 사이드 렌더링과 같이 변하지 않는 핵심 로직 위주로 테스트하는 것이 효율적일 수 있습니다.

SWR의 캐시 동작 방식을 파악하기 위해 테스트 코드를 살펴보면, 캐시 업데이트 및 뮤테이트 시 캐시된 밸류를 확인하는 테스트를 확인할 수 있습니다. 테스트 코드와 함께 **친절하게 작성된 주석**은 코드의 동작 방식을 이해하는 데 큰 도움을 줍니다.

🗑️ 메모리 누수 방지를 위한 위크 맵(WeakMap) 활용

SWR은 캐시 데이터를 관리하기 위해 위크 맵(WeakMap)을 사용합니다. **위크 맵은 키로 쓰인 객체가 가비지 컬렉션 대상이 되도록 하여 메모리 누수를 방지**합니다. 캐싱은 있으면 좋지만 필수는 아니므로, 메모리 관리를 위해 위크 맵을 사용하는 것이 합리적입니다.

✨ 유즈 아이소모픽 레이아웃 이펙트(useIsomorphicLayoutEffect)의 활용

SWR에서는 `useIsomorphicLayoutEffect`라는 Hook을 사용합니다. 서버 환경과 클라이언트 환경을 구분하여 `useEffect`와 `useLayoutEffect`를 선택적으로 실행합니다. **서버에서는 `useLayoutEffect`가 제대로 동작하지 않기 때문에 분기 처리**를 해주는 것입니다.

🛠️ 깃 렌즈(GitLens) 확장 프로그램 활용

깃 렌즈(GitLens) 확장 프로그램을 사용하면 **누가 언제 커밋했는지, 어떤 PR과 관련 있는지** 등을 쉽게 확인할 수 있습니다. 또한, 깃허브의 릴리즈 노트를 통해 라이브러리의 변경 사항을 빠르게 파악할 수 있습니다.

🤝 오픈 소스 참여, 어떻게 시작해야 할까요?

오픈 소스에 기여하고 싶다면, 깃허브에서 'Good First Issue' 라벨이 붙은 이슈부터 시작하는 것이 좋습니다. 또한, 라이브러리의 컨트리뷰팅 가이드나 README를 참고하면 더욱 쉽게 참여할 수 있습니다. **개인 프로젝트에서도 README를 잘 작성하는 것은 좋은 습관**입니다.

핵심 개념 위주로 하나씩 파고들면서 라이브러리를 분석하면 재미있게 학습할 수 있습니다. 테스트 코드, 주석, 깃허브 정보 등을 적극적으로 활용하여 오픈 소스 라이브러리 분석 능력을 향상시키세요!

오픈 소스 라이브러리 분석의 필요성 및 SWR 소개

좋은 코드 작성을 위해 오픈 소스 라이브러리 분석의 중요성을 강조하며, 예시로 SWR 라이브러리 소개.

SWR 라이브러리 분석 방법에 대한 고민 공유.

SWR은 데이터 관리 및 로딩 상태 처리에 유용한 라이브러리.

SWR의 주요 기능(뮤터블, 인피니트, 뮤테이트) 언급 및 멀티 패키지 구조 설명.

라이브러리 분석 시 테스트 코드부터 보는 것을 추천.

테스트 코드를 통해 코드 동작 방식 및 예외 케이스 파악 가능.

SWR의 E2E 테스트 코드 분석 시작.

E2E 테스트 존재에 대한 의문 제기 및 테스트 내용 확인.

플레이 라이트 사용 및 기본적인 SSR, 하이드레이션 테스트 확인.

E2E 테스트의 유용성과 유지보수 비용에 대한 의견 제시.

캐시 동작 방식에 대한 궁금증 해결을 위해 관련 테스트 코드 분석.

캐시 업데이트 및 뮤테이트 시 캐시된 값 확인 테스트 분석.

테스트 코드 예시를 통해 뮤테이트 실행 시 데이터 변경 확인.

렌더위 컴피그 컴포넌트 분석 및 리액트 켓 라이브러리 활용 확인.

SWR 주석 활용 및 키 값 동작 방식 이해

SWR의 친절한 주석을 통해 코드 동작 방식 쉽게 이해 가능.

중첩된 컴포넌트에서 동일한 키 값을 사용할 때의 동작 방식 설명.

키 값뿐만 아니라 컴포넌트까지 고려하여 데이터가 다르게 나올 수 있음을 설명.

캐시 생성 과정 분석을 위해 인터널 폴더의 캐시 관련 코드 확인.

SWR 글로벌 스테이트가 없을 때 빈 객체 생성 및 초기화 과정 설명.

위크 맵을 사용하여 캐시 데이터를 관리하는 이유 설명.

위크 맵의 가비지 컬렉션 장점 및 캐싱에 적합한 이유 설명.

useIsomorphicLayoutEffect 훅 사용 이유 분석.

서버 환경에 따른 분기 처리 이유를 주석을 통해 파악.

useEffect와 useLayoutEffect의 차이점 설명 및 서버 사이드 렌더링 시 문제점 해결 방식 설명.

SWR 분석 시 주석 활용 및 검색을 통해 정보 획득 가능.

깃 렌즈 확장 프로그램 소개 및 활용 방법 설명.

깃허브를 통해 라이브러리 이해도를 높이는 방법 및 이슈 남기는 방법 소개.

컨트리뷰트 가이드 및 리드미 활용 팁 제시.

라이브러리 분석 방법 요약 및 마무리.

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

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

스크립트