SWR 2.0뭐가 바뀌었을까 ~ ?

영어 공부할겸, 저희 회사 주스택인 SWR도 공부할겸 이렇게 적어봅니다. 
오역이 굉장히 많을 것으로 생각됩니다. 피드백좀...


https://swr.vercel.app/ko/blog/swr-v2

Announcing SWR 2.0 – SWR

 

We are thrilled to announce the release of SWR 2.0, the popular React data-fetching library that enables components to fetch, cache, and mutate data and keeps the UI up-to-date with changes in that data over time.

 

This new version comes packed with improvements and new features, such as new mutation APIs, improved optimistic UI capabilities, new DevTools, and better support for concurrent rendering. We would like to extend a huge thank you to all the contributors and maintainers who made this release possible.

컴포넌트상에서 패치, 캐싱, 그리고 데이터 뮤테이트와 시간이 지남에 따라서 최신상태의 UI로 유지시켜주는, 인기 폭팔 중인 리액트 데이터 패칭 라이브러리, SWR 2.0을 출시를 발표하게 되어 굉장히 떨립니다.

이 새로운 버전은 더 나은 동시성 렌더링 지원, 새로운 개발 도구들, 개선된 낙관적 UI 능력, 새로운 뮤테이션 API들같은 새로운 개선점과 새로 기능들로 가득 차있습니다. 저희는 이 출시를 할 수 있게 만들어준 모든 컨트리뷰터와 메인터너스 감사를 돌리고 싶습니다. 

---

Mutation and Optimisctic UI

 

useSWRMutation 

 

Mutation is an important part of the data-fetching process. They allow you to make changes to your data both locally and remotely. Our existing mutate API allows you to revalidate and mutate resources manually. In SWR 2.0, the new hook useSWRMutation makes it even simpler to remotely change data using a declarative API. You can set up a mutation using the hook, and then activate it later:

뮤테이션은 데이터 패칭 과정에서 중요한 부분입니다. 로컬에서 혹은 서버쪽으로 데이터에 변화를 줄 수 있도록 해줍니다. 이미 있는 뮤테이트 API는 갱신과 리소스 변화를 수동으로 할 수 있도록 해줍니다. SWR 2.0에서부터는 새로운 훅인 useSWRMutation이 선언적 API를 사용해 원격상의 데이터에 변화를 더 쉽게 할 수 있습니다. 훅을 사용해서 Mutation을 준비해두고, 나중에 활성화 시킬 수 있습니다. 

 

The example above defines a sendRequest mutation that affects the '/api/user' resource. Unlike useSWR, useSWRMutation will not immediately start the request upon rendering. Instead, it returns a trigger function that can later be called to manually start the mutation.

위 예시에서 '/api/user' 리소스에 영향을 주도록 sendRequest 뮤테이션 정의했습니다. useSWR과 달리. useSWRMutation은 렌더링과 동시에 바로 요청을 시작하지 않을 겁니다. 대신에 Mutation을  수동으로 호출 할 수 있도록 trigger라는 함수를 반환합니다.

 

The sendRequest function will be called when the button is clicked, with the extra argument { username: 'johndoe' }. The value of isMutating will be set to true until the mutation has finished. Additionally, this new hook addresses other issues you may have with mutations:

저 sendRequest 함수는 버튼이 클릭될 때, { username: 'johndoe' } 라는 추가적인 인자와 함께 호출이 될겁니다. isMutating이라는 값은 뮤테이션이 끝날때까지 true로 되어있을겁니다. 추가적으로, 이 새로운 훅은 다른 뮤테이션 관련 이슈들도 해결합니다. 

 

• Optimistically update the UI while data is being mutated
• Automatically revert when mutation fails
• Avoid any potential race conditions between useSWR and other mutations of the same resource
• Populate the useSWR cache after mutation completes

- 데이터가 변화할 동안 UI를 낙관적으로 업데이트
- 뮤테이션 실패시 자동으로 되돌림
- 같은 리소스의 다른 뮤테이션들과 useSWR 사이에 race 조건의 가능을 피하기
- 뮤테이션이 완료되면 useSWR 캐시에 적용

 

Optimistic UI

 

Optimistic UI is an excellent model for creating websites that feel fast and responsive; however, it can be difficult to implement correctly. SWR 2.0 has added some new powerful options to make it easier.

 

Let’s say we have an API that adds a new todo to the todo list and sends it to the server:

낙관적 UI는 웹사이트가 빠르고 반응적으로 느껴지게 만들어주는 훌륭한 모델입니다. 그러나 올바르게 구현하는 것은 어려울 수 있습니다. SWR 2.0는 이를 좀 더 쉽게 만들어줄 강력한 옵션들을 추가했습니다. 

투두 리스트에 새로운 투두를 추가하고 서버로보내는 API가 있다고 가정해봅시다. 

 

 

In our UI, we use a useSWR hook to display the todo list, with an “Add New Item” button that triggers this request and asks SWR to re-fetch the data via mutate():

우리 UI에서는, useSWR 훅을 사용해서 투두 리스트를 보여주고, 새로운 아이템 추가 버튼으로 이 요청을 호출하고 SWR에 데이터를 mutate()를 통해 갱신합니다.

 

 

 

However, the await addNewTodo(...) request could be very slow. When it’s ongoing, users still see the old list even if we can already know what the new list will look like. With the new optimisticData option, we can show the new list optimistically, before the server responds:

그러나, await addNewTodo() 요청이 느릴수도 있습니다. 요청되는 동안, 유저들은 새로운 리스트가 어떻게 될지 앎에도 불구하고 기존의 리스트를 보게됩니다. 새로 optimisticData 옵션 사용하면, 새 리스트를 서버가 응답하기 전에 낙관적으로 우리는 보여줄 수 있습니다. 

 

SWR will immediately update the data with the optimisticData value, and then send the request to the server. Once the request finishes, SWR will revalidate the resource to ensure it’s the latest.

SWR은 즉각적으로 optimisticData 값으로 데이터를 업데이트하고, 그리고 나서 서버에 요청을 보냅니다. 요청이 끝나고 나면, SWR은 최신상태를 보장하기 위해 리소스를 갱신합니다. 

 

 

Like many APIs, if the addNewTodo(...) request returns us the latest data from the server, we can directly show that result, too (instead of starting a new revalidation)! There’s the new populateCache option to tell SWR to update the local data with the mutate response:

많은 API들 처럼, 만약 the addNewTodo() 요청이 서버로부터 최신 데이트를 우리에게 반환한다면, 그것또한 바로 결과를 보여줄 수 있습니다(새로운 갱신을 시작하기 전에). 뮤테이트 응답으로 로컬 데이터를 업데이트 할 수 있도록 새로운 populateCache 옵션이 있습니다. 

 

 

 

At the same time, we don’t need another revalidation afterward as the response data is from the source of truth, we can disable it with the revalidate option:

그와 동시에, 응답데이터가 신뢰할만한 리소스이므로 이후에 다른 갱신을 할 필요가 없습니다. 이때 revalidate 옵션을 끌 수 있습니다. 

 

Lastly, if addNewTodo(...) fails with an exception, we can revert the optimistic data ([...data, 'New Item']) we just set, by setting rollbackOnError to true (which is also the default option). When that happens, SWR will roll back data to the previous value.

마지막으로, 만약 addNewTodo()가 예외와 함께 요청을 실패하면, 우리는 rollbackOnError을 true로 설정 해놓음으로 optimistic data를 되돌릴 수 있습니다. 그때, SWR은 데이터를 이전 값으로 롤백합니다. 

 

All these APIs are supported in the new useSWRMutation hook as well. To learn more about them, you can check out our docs. And here is a demo showing that behavior:

이 모든 API들이 새로운 useSWRMutation 훅에서 다 지원이 됩니다. 더 배우기 위해서는 docs를 확인해보세요. 동작을 보여주는 데모도 있습니다. 

 

 

Mutate Multiple Keys

 

The global mutate API now accepts a filter function, where you can mutate or revalidate specific keys. This will be helpful for use cases such as invalidating all the cached data. To learn more, you can read Mutate Multiple Keys in the docs.

전역 뮤테이션 API에서 특정 키를 갱신 혹은 뮤테이트하는 곳에 필터 함수를 받을 수 있습니다. 유효하지않은 모든 캐싱 데이터와 같은 유스케이스에 대해 도움될 것입니다. 더 알아보고 싶다면 docs에서 Mutate Multiple Keys를 읽어주세요.

 

---

SWR DevTools 

 

SWRDevTools(opens in a new tab) is a browser extension that helps you debug your SWR cache and the fetch results. Check our devtools section for how to use devtools in your application.

SWRDevTools는 패치 결과와 SWR 캐시의 디버그를 도와주는 브라우저 익스텐션입니다. devtool 섹션에서 어떻게 사용하는지 확인하세요.

 

 

---

Preloading Data

 

Preloading data can improve the user experience tremendously. If you know the resource is going to be used later in the application, you can use the new preload API to start fetching it early:

데이터 프리로딩을 UX를 엄청나게 개선할 수 있습니다. 만약 당신이 해당 리소스가 애플리케이션에서 언제가 곧 쓰일 것을 알고 있다면, 새로운 preload API를 사용해서 일찍 페칭을 할 수 있습니다. 

 

In this example, the preload API is called in the global scope. This means that we start to preload the resource before React even starts to render anything. And when the Profile component is being rendered, the data can probably be available already. If it’s still ongoing, the useSWR hook will reuse that ongoing preloading request instead of starting a new one.

 

The preload API can also be used in cases like preloading data for another page that will likely be rendered. More information about prefetching data with SWR can be found here.

이 예시에서는, 전역 스코프에서 preload API가 호출되었습니다. 이건 리액트가 아직 렌더를 아무것도 시작도하기 전에 그 리소스를 프리로드를 할 수 있다는 것을 의미합니다.  그리고 Profile 컴포넌트가 렌더링이 되어갈때, 그 데이터는 아마 이미 사용가능한 상태일 겁니다.  만약 아직 진행중이라면, useSWR 훅은 새요청을 시작하는 대신 진행 중인 프리로딩 요청을 재사용합니다. 

프리로드 API는 렌더링될 다른 페이지의 데이터를 미리 로드하는 등의 경우에도 사용할 수 있습니다. SWR을 통한 프리페칭 데이터에 관해서는 링크를 참조해주세요. 

---

isLoading

 

isLoading is a new state returned by useSWR, that indicates if the request is still ongoing, and there is no data loaded yet. Previously, the isValidating state represents both the initial loading state and revalidating state so we had to check if both data and error are undefined to determine if it was the initial loading state.

 

Now, it is so easy that you can directly use the isLoading value to render a loading message:

만약 요청이 여전히 진행중이거나 데이터가 없는것에 을 나타내는 isLoading은 useSWR에서 반환하는 새로운 상태입니다. 이전에는, isValidating 상태가 초기 로딩 상태와 상태를 갱신하는 것을 둘다 대변 했어서 데이터와 오류가 모두 undefined인지 확인하여 초기 로딩 상태인지 확인해야 했습니다.

이제는, isLoading 값을 사용하여 바로 로딩 메세지를 렌더하기 매우 쉬워졌습니다.

 

Note that isValidating is still present so you can still use it to show a loading indicator for revalidations.

isValidating은 여전히 현역이고, 갱신에 대한 로딩 지표를 보여줄 때 사용할 수 있다는걸 명심해주세요. 

 

---

Preserving Previous State

 

The keepPreviousData option is a new addition that allows you to keep the data that was fetched before. This improves UX immensely when you’re fetching data based on user actions happening in real time, like with a live search feature, where the resource’s key keeps changing:

keepPreviousData 옵션은 패치되기전에 데이터를 유지할 수 있도록해주는 새로운 옵션입니다. 리소스의 키가 계속 변경되는 라이브 검색 기능과 같이 실시간으로 발생하는 사용자 행동을 기반으로 데이터를 가져올 때 UX가 크게 개선됩니다:

 

---

Extending Configurations

 

SWRConfig can now accept a function value. When you have multiple levels of <SWRConfig>, the inner receives the parent configuration and returns a new one. This change makes it more flexible to configure SWR in a large codebase. More information can be found here.

SWRConfig는 이제 함수값을 받을 수 있습니다. 만약 다중 계층의 SWRConfig 래퍼를 가지고 있다면, 안쪽에 있는게 부모 설정을 받고 새로운 설정을 반환합니다. 이 변경점은 좀 더 큰 코드베이스에서 좀 더 유동적인 SWR 설정을 만들어줍니다. 

 

---

Improved React 18 Suppert

 

SWR has updated its internal code to use useSyncExternalStore and startTransition APIs in React 18. These ensure stronger consistency when rendering UI concurrently. This change doesn’t require any user code changes and all developers will benefit from it directly. Shims are included for React 17 and below.

SWR 2.0 and all the new features are still compatible with React 16 and 17.

SWR은 리액트 18버전의 useSyncExternalStore and startTransition API를 사용하기 위해 내부코드를 수정했습니다. 동시적으로 UI가 랜더링 될때, 더 강력한 일관성을 보장합니다. 이 변화에 대해서는 어떠한 유저 코드의 변화를 요하지도 않고, 모든 개발자들이 바로 이 이점을 바로 받을 수 있습니다. shime들은 React 17 버전 혹은 이하버전부터 포함되어 있습니다. 

SWR 2.0과 새 기능들은 여전히 리액트 16,17 버전들과 호환됩니다. 

---

Migration Guide

 

Fetcher는 다중 인자를 더 이상 받지 않습니다.

key는 하나의 인자만 넘깁니다. 

 

전역 뮤테이트트 더 이상 getKey 함수를 받지 않습니다. 

이제 전역변수에 함수를 넘기면 filter로써 사용될 겁니다. 이전에는 전역 뮤테이트에 키를 반환하는 함수를 넘길 수 있었습니다.

 

캐시 상호를 위한 새로운 keys 속성이 필수가 되었습니다. 

자체 캐시 구현을 사용할때, 캐시 인턴페이스에는 자바스크립트 맵 인스턴스들과 유사하게 캐시 객체의 모든 키를 반환하는 keys() 메소드가 필요합니다. 

 

 

Changed Cache Internal Structure

캐시 데이터의 내부 구조는 모든 현재 상태를 가지고있는 객체일 겁니다.

 

SWRConfig.default Is Renamed as SWRConfig.defaultValue

SWRConfig.defaultValue 는 기본 SWR 설정에 접근하기 위한 속성 입니다.  

 

InfiniteFetcher가 SWRInfiniteFetcher로 이름이 수정되었습니다.

 

Avoid Suspense on Server

만약 Nextjs안에서 pre-rendering을 포함해, 서버사이드 상에서 SWR로 suspense: true 사용하기 위해서는 fallbackData 혹은 fallback을 통해서 초기 데이터값을 제공해야합니다. 현재, 서버사이드에서는 데이터를 패치하기 위해 Suspense를 사용할 수 없다는 것을 뜻합니다. 다른 두가지 옵션은 완전히 클라이언트측에서 데이터 패칭을 하거나 프레임워크가 데이터를 가져오도록 하는 것입니다. ( Nextjs의 getStaticProps 처럼 )