[내보내번] Next.js docs - Fast Refresh

내보내번(내가 보려고 내가 번역한...) Next.js docs

2021년 4월 2일 기준 Next.js 공식 문서를 번역했다.

※ 영어 전공자도 해외 유학파도 아니기에 번역에는 의역, 오역, 구글 번역이 무수히 많을 수 있으며, 혼자 공식문서를 참조해가며 번역하다 보니 오타도 많을 수 있다. 정확한 내용은 공식문서를 직접 살펴보거나 다른 정보들을 더 찾아보는 것을 추천한다.
(하지만 댓글 피드백도 환영합니다😃 )
이번 글은 아직 몇 개 안 되는 내보내번 중에 제일 별로 인 것 같다... React에 대한 이해 및 영어 실력 모두 하찮은 탓인가... (앞으로 얼마나 더 많은 제일 별로인 글이 나올지는 모르겠지만🤔)

Next.js 공식문서 확인하기>>

Basic Features: Fast Refresh | Next.js

---

 

Fast Refresh is a Next.js feature that gives you instantaneous feedback on edits made to your React components. Fast Refresh is enabled by default in all Next.js applications on 9.4 or newer. With Next.js Fast Refresh enabled, most edits should be visible within a second, without losing component state.

Fast Refresh는 React 컴포넌트들을 편집되었을 때 즉각적인 피드백을 주는 Next.js의 기능이다. 9.4 혹은 더 상위 버전의 Next.js 어플리케이션에서 Fast Refresh는 기본으로 활성화가 되어있다. Next.js Fast Refresh가 활성화하면 대부분의 편집에 대해서 컴포넌트 상태를 잃지 않고 1초 내에 보여지게된다. 

How It works

• If you edit a file that only exports React component(s), Fast Refresh will update the code only for that file, and re-render your component. You can edit anything in that file, including styles, rendering logic, event handlers, or effects.
• If you edit a file with exports that aren't React components, Fast Refresh will re-run both that file, and the other files importing it. So if both Button.js and Modal.js import theme.js, editing theme.js will update both components.
• Finally, if you edit a file that's imported by files outside of the React tree, Fast Refresh will fall back to doing a full reload. You might have a file which renders a React component but also exports a value that is imported by a non-React component. For example, maybe your component also exports a constant, and a non-React utility file imports it. In that case, consider migrating the constant to a separate file and importing it into both files. This will re-enable Fast Refresh to work. Other cases can usually be solved in a similar way.
• React 컴포넌트들만을 export하는 파일을 편집한 경우, Fast Refresh는 해당 파일의 코드만 업데이트하고 컴포넌트를 다시 렌더 할 것이다. 해당 파일의 스타일, 렌더링 로직, 이벤트 핸들러 혹은 effects를 포함한 어떤 것도 편집할 수 있다. 
• React 컴포넌트가 아닌 export로 파일을 편집한 경우(?), Fast Refresh는 편집한 해당 파일과 이 파일을 import하는 다른 파일들 모두를 다시 동작시킬 것이다. 그래서 만약 Button.js와 Modal.js 모두 theme.js를 가져오는 경우, theme.js를 편집하면 Button.js, Modal.js 두 컴포넌트 모두 업데이트될 것이다. 
• 마지막으로 React 트리 외부의 파일에서 import한 파일을 편집하는 경우, Fast Refresh는 full reload를 진행할 것이다. React 컴포넌트를 렌더 하지만 또한 non-React 컴포넌트로부터 가져온 값을 export 하는 파일이 있을 수도 있다. 예를 들어, 컴포넌트가 constant를 export 하고 non-React 유틸리티 파일이 constant를 import 할 수 있다.(?) 그런 경우 그 constant를 분리된 파일로 migrating 하고 두 파일들로 import 하는 것을 고려해 볼 수 있다. 이렇게 하면 Fast Refresh를 다시 활성화시킬 수 있다. 다른 경우들도 비슷한 방법으로 해결할 수 있다. (이런 케이스들을 잘 모르겠어서 이해가 잘 안됨...)

Error Resilience

Syntax Errors

If you make a syntax error during development, you can fix it and save the file again. The error will disappear automatically, so you won't need to reload the app. You will not lose component state.

만일 개발환경에서 구문 오류를 만든 경우, 수정해서 파일을 다시 저장할 수 있다. 에러는 자동으로 사라질 것이고 앱을 다시 로드할 필요가 없다. 컴포넌트의 상태를 잃지 않을 것이다. 

Runtime Errors

If you make a mistake that leads to a runtime error inside your component, you'll be greeted with a contextual overlay. Fixing the error will automatically dismiss the overlay, without reloading the app.

컴포넌트 내에 런타임 오류를 만드는 실수를 한 경우, 문맥(contextual) 오버레이를 마주하게 될 것이다. 오류를 수정하면 앱을 재로드 하지 않아도 오버레이가 자동으로 사라질 것이다. 

Component state will be retained if the error did not occur during rendering. If the error did occur during rendering, React will remount your application using the updated code.

렌더링 중에 오류가 발생하지 않는 경우 컴포넌트 상태는 유지될 것이다. 렌더링 중에 오류가 발생하면, React는 업데이트된 코드를 사용하여 어플리케이션을 다시 마운트 할 것이다. 

If you have error boundaries in your app (which is a good idea for graceful failures in production), they will retry rendering on the next edit after a rendering error. This means having an error boundary can prevent you from always getting reset to the root app state. However, keep in mind that error boundaries shouldn't be too granular. They are used by React in production, and should always be designed intentionally.

앱에 에러 경계가 있으면 (운영환경에서 우아한 실패를 위해선 좋은 아이디어이다 -> 리액트 공식 문서 에러 경계 관련 내용에서 "UI의 일부분에 존재하는 자바스크립트 에러가 전체 애플리케이션을 중단시켜서는 안 됩니다." 말은 에러 경계는 전체 앱이 중단되는 것이 방지하기 위해 고안되었기 때문에 우아한 실패라는 표현을 사용하는 것으로 보임.), 렌더링 오류 후에 다음 편집 시 렌더링을 재시도할 것이다. 이 의미는 에러 경계를 갖는 것이 항상 root 앱 상태부터 리셋하는 것을 막아줄 수 있다는 것이다. 그러나 오류 경계가 너무 세분화되어서는 안 된다는 것을 기억하라. 에러 경계는 React 운영 환경에서 사용되며 항상 의도적으로 설계되어야한다. (?)

Error boundaries are React components that 
catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI
 instead of the component tree that crashed. Error boundaries catch errors during rendering, in lifecycle methods, and in constructors of the whole tree below them.

에러 경계는 
하위 컴포넌트 트리의 어디에서든 자바스크립트 에러를 기록하며 깨진 컴포넌트 트리 대신 폴백 UI를 보여주는
 React 컴포넌트입니다. 에러 경계는 렌더링 도중 생명주기 메서드 및 그 아래에 있는 전체 트리에서 에러를 잡아냅니다.
https://ko.reactjs.org/docs/error-boundaries.html#introducing-error-boundaries

Limitations

Fast Refresh tries to preserve local React state in the component you're editing, but only if it's safe to do so. Here's a few reasons why you might see local state being reset on every edit to a file:

Fast Refresh는 수정하고 있는 컴포넌트의 로컬 React 상태를 유지하려고 하는데 그렇게 하는 것이 안전한 경우에만 유지하려고 한다. 아래는 왜 로컬 상태가 매 파일 편집 시마다 리셋되는지에 대한 몇 가지 이유들이다. 

• Local state is not preserved for class components (only function components and Hooks preserve state).
• The file you're editing might have other exports in addition to a React component.
• Sometimes, a file would export the result of calling higher-order component like HOC(WrappedComponent). If the returned component is a class, state will be reset.
• Anonymous arrow functions like export default () => <div />; cause Fast Refresh to not preserve local component state. For large codebases you can use our name-default-component codemod.
• 로컬 상태는 클래스 컴포넌트들을 위해서는 유지되지 않는다. (함수형 컴포넌트와 Hooks만 상태를 유지한다)
• 편집하고 있는 파일이 React 컴포넌트 외에 다른 export가 있을 수 있다.
• 때때로 파일은 HOC (WrappedComponent)와 같은 higher-order 컴포넌트를 호출한 결과를 내 보낸다. 반환받은 컴포넌트가 클래스인 경우 상태는 리셋된다.
• export default () => <div />;와 같은 익명 화살표 함수는 Fast Refresh로 로컬 구성 요소 상태를 유지하지 못한다. 큰 규모의 코드 베이스의 경우 name-default-component codemod를 사용할 수 있다. 

 

As more of your codebase moves to function components and Hooks, you can expect state to be preserved in more cases.

코드 베이스들이 함수형 컴포넌트나 Hooks으로 옮겨 감에 따라 더 많은 경우 상태가 유지될 것을 기대할 수 있다. 

Tips

• Fast Refresh preserves React local state in function components (and Hooks) by default.
• Sometimes you might want to force the state to be reset, and a component to be remounted. For example, this can be handy if you're tweaking an animation that only happens on mount. To do this, you can add // @refresh reset anywhere in the file you're editing. This directive is local to the file, and instructs Fast Refresh to remount components defined in that file on every edit.
• You can put console.log or debugger; into the components you edit during development.
• Fast Refresh는 기본적으로 함수형 컴포넌트(와 Hooks)에서의 React 로컬 상태를 유지한다.
• 때때로 강제로 상태를 리셋하고 컴포넌트가 리 마운트 시키고 싶을 수 있다. 만약 마운트 시에만 애니메이션을 조정하는 경우 이 방법이 편리할 수 있다. 이렇게 하려면 // @refresh reset을 파일에서 편집하는 어느 곳이든 추가하라. 이 지시문은 파일의 로컬이며(지시문의 적용범위가 해당 파일이라는 의미인 것으로 보임), Fast Refresh가 그 파일 내에 정의된 컴포넌트를 매 편집 시에 다시 마운트 하도록 지시한다.(?)
• 개발 중에는 console.log나 debugger;를 편집하는 컴포넌트에 추가할 수 있다.

Fast Refresh and Hooks

When possible, Fast Refresh attempts to preserve the state of your component between edits. In particular, useState and useRef preserve their previous values as long as you don't change their arguments or the order of the Hook calls.

가능한 경우 Fast Refresh는 컴포넌트 편집 사이에 상태를 유지하려고 시도한다. 특히 useState와 useRef는 그들의 인수나 Hooks 호출 순서를 변경하지 않는 한 이전 값을 유지한다.

Hooks with dependencies—such as useEffect, useMemo, and useCallback—will always update during Fast Refresh. Their list of dependencies will be ignored while Fast Refresh is happening.

useEffect, useMemo, useCallback과 같은 종속성이 있는 Hooks는 Fast Refresh 동안에 항상 업데이트 할 것이다. Fast Refresh가 일어나는 동안에는 종속성 목록은 무시될 것이다. 

For example, when you edit useMemo(() => x * 2, [x]) to useMemo(() => x * 10, [x]), it will re-run even though x (the dependency) has not changed. If React didn't do that, your edit wouldn't reflect on the screen!

예를 들어, useMemo(() => x * 2, [x]) 를 useMemo(() => x * 10, [x])로 편집하면 x(종속성)가 변경되지 않았지만 재 실행할 것이다. React가 그렇게 하지 않으면 수정된 것이 화면에 반영되지 않을 것이다.

Sometimes, this can lead to unexpected results. For example, even a useEffect with an empty array of dependencies would still re-run once during Fast Refresh.

때때로 이로 인해 예상치 못한 결과가 나올 수도 있다. 예를 들어, useEffect를 빈 종속성 배열과 사용하는 경우 여전히 Fast Refresh 중에 한번 재실행될 것이다. 

However, writing code resilient to occasional re-running of useEffect is a good practice even without Fast Refresh. It will make it easier for you to introduce new dependencies to it later on and it's enforced by React Strict Mode, which we highly recommend enabling.

하지만 useEffect이 가끔 실행되게 하기 위한 탄력적인 코드 작성은 Fast Refresh를 제외하고도 좋은 연습이다. 나중에 새로운 종속성을 더 쉽게 도입할 수 있고 React Strict Mode에 의해 적용되며, 활성화하는 것이 좋다. (?)