이 글은 React I Love You, But You're Bringing Me Down을 페이스북의 dan_abramov님이 읽고 남긴 트윗을 번역한 글입니다.
번역된 원본글은 [번역] 리액트, 널 사랑하지만 넌 날 슬프게 해 입니다.
글에 대한 답장인 만큼 위의 번역된 글과 함께 봐주시면 편합니다.
직역보다는 뜻을 살린 의역을 했습니다. 만약 번역이 잘못된 부분이 있다면 꼭 알려주세요!
답장
서문
happy to briefly respond to each point. not sure i agree with all of them
간단히 각 문장에 답장을 남길 수 있어 기쁘네요. 다만 이 글 전부에 동의하는 건 아닙니다.
그건 바로 너였어 (You Were The One)
forms, yeah they’re hard but the domain is generally hard. the svelte example quoted at the end seems like syntax sugar for the simple case, so it’s unclear why it’s purported to be solving the issues outlined by the author (validation, depending inputs etc).
폼, 분명 어려운 건 맞지만 폼은 그 자체로도 어렵습니다. 마지막에 인용된 svelte 예제는 단순한 사례에 들어가는 문법적 설탕 같이 보여서, 폼이 개발자에 의해 조절되는 부분(입력에 따라 달라지거나, 유효성 검사 등)이 해결된다는 주장에 동의하기 어렵네요.
i agree that if you feel like the vanilla way is verbose, you might be tempted to use a library, and then it’s unclear which one to choose. i’m not sure what makes Formik “slow for large forms” — how large? what logic is so expensive? is it measured in production mode?
저는 당신이 바닐라의 방식이 장황하다고 생각한다면, 라이브러리를 사용하고 싶다는 유혹이 생긴다는 것과, 어떤 라이브러리를 골라야 하는지 확실하지 않다는 것도 동의합니다.
(그러나) 저는 Formik가 '큰 폼을 느리게' 만든다는 것은 의아하게 느껴지네요. 얼마나 큰 건가요? 무슨 로직이 그렇게 복잡한가요? 프로덕션에서도 발생하나요?
당신은 너무 Context에 예민해요 (You're Too Context Sensitive)
- context. there is absolutely nothing wrong with the provider tree in that example. it’s good practice to split contexts — not just for performance but because they are unrelated, and you might want to override a part down the tree without affecting other ones.
context, 저 예*에서는 provider에 아무런 문제가 없습니다. 성능 뿐만 아니라, 각 데이터를 서로 관계가 없기 때문에 context를 분리하는 것이 좋습니다. 그리고 다른 context의 영향 없이 트리 아래 부분을 다시 짤 수 있습니다.
*예: 글에서 언급된 context provider가 많이 중첩된 코드
now, i agree that re-renders can be frustrating if you’re relying on context a lot and it changes often. it’s easy to solve by splitting a component in two + adding memo below, but i agree this is annoying and not obvious.
저는 당신이 context에 큰 의존성이 있고, 또 자주 바뀐다면, 리렌더링이 불만스러워진다는 것에 동의합니다. 컴포넌트를 둘로 나누고 + useMemo를 추가한다면 쉽게 해결할 수 있긴 하지만, 짜증나고 불분명해진다는 것도 맞다고 생각합니다.
we don’t want to solve this for context alone because the issue is more general. selectors as main API lead to very unnatural code over time — look at how reselect is used in redux apps. we are working to solve memoization for good with a compiler instead
우리는 이 이슈가 더 일반적이기 때문에, context 만으로 해결하고 싶지는 않습니다. 기본 API인 selectors(셀렉터)는 시간이 지날 수록 부자연스러운 코드로 이어집니다. redux 앱에서 reselect가 어떻게 사용되고 있는지 확인해보세요. 대신 저희는 컴파일러를 통해 memoization을 해결할 좋은 방법을 찾기 위해 일하고 있습니다.
나는 이 중 어느 것도 원하지 않아요 (I Want None Of This)
- the forwardRef example is 100% valid. in fact getting to the stage the person wants (just passing a ref attribute) was the reason forwardRef was introduced. it’s a temporary step because otherwise it would be a big breaking change. the plan is to remove the need for it.
그 forwardRef 예시는 아무런 문제가 없습니다. 실제로 개발자가 원하는 단계로 도달(ref 속성을 전달하는 것)이 바로 forwardRef가 도입된 이유입니다. 만약 그렇지 않으면 큰 변화가 필요하기 때문에 임시적인 단계입니다. 그 계획은 그것의 필요성을 없애는 것입니다.
나비효과 (The Butterfly (use) Effect)
- re: effects being confusing, this tends to happen when your effects aren’t used for synchronizing. i don’t know what queryModifiers are in this example, but this logic to me looks like logic that should run during rendering. we agree: it’s not needed
effect 는 혼란스럽습니다. 이것들은 당신의 effect가 동기화를 위해 사용되지 않을 때도 발생하는 경향이 있습니다. 저는 저 예에서 queryModifiers가 어떤 것인지는 모르지만, 이 로직은 렌더링 중에서도 실행되어야 하는 것 처럼 보이네요. 우리는 동의합니다: 이것이 필요하지 않다고.
https://beta.reactjs.org/learn/you-might-not-need-an-effect
re: useCallback — again totally valid feedback, and that’s what the compiler project is meant to address. if it works out you’d be able to write them as plain functions. keep in mind there’s no reason to useCallback for something like handleClick unless you pass it down to memo.
useCallback, 이는 정말 적절한 피드백입니다, 그리고 이게 바로 컴파일러 프로젝트가 해결해야 하는 것입니다. 만약 이게 해결된다면, 일반함수처럼 작성할 수 있을겁니다. handleClick 같은 것을 memo에 전달하지 않는 한 useCallback을 사용할 이유가 없다는 것을 알아두세요.
핵심을 개선해요 (Makeup Your Mind)
- re: “gimmicks” like useSyncExternalStore. they’re not to make the code look “beautiful”. on the contrary, they look a bit more ugly but the purpose is to remove the need to use effects to the minimum, and cover all specific use cases with targeted primitives that work better
useSyncExternalStore 같은 기믹은 코드를 아름답게 보이게 하지 않습니다. 반대로, 저것들은 조금 더럽게 보이더라도, effect를 최소한에 가깝게 줄이고, 더 잘 돌아가는 기본적인 요소로 모든 특정한 사례를 해결하는 것이 목표입니다.
the goal there isn’t to make effects “easier to use”. it’s to remove effects altogether as much as possible. yes, there is some unfortunate API area growth there, but it’s worth it to remove effects and get semantically better behavior. these are escape hatches, not main APIs
effect를 '사용하기 쉽게' 만드는 것이 목표가 아닙니다. 가능한 effect를 최대한 제거하는 것이 그 목표입니다. 맞아요, 약간은 불행한 API 영역 확장이 있습니다. 그럼에도 effect를 제거하고 의미론적으로 더 나은 동작을 얻을 만한 가치가 있습니다. 저것들은 탈출 해치이지, 메인 API가 아닙니다.
엄격해요 (Strict Machine)
the easy (and preferred) solution there is to split the component in two and place the early return in the outer component. then none of what’s described below is needed. i agree we should teach this better.
컴포넌트를 둘로 나누고 바깥 컴포넌트에서 return을 해주는 것이 쉽고 선호되는 방법입니다. 이 경우 아래에 설명된 어떤 것도 필요하지 않습니다. 저희가 이런 것들을 조금 더 알려드려야 한다는 것에 동의합니다.
너무 오래되었어요 (You've Been Gone Too Long)
fragmentation
that’s fair but you can always expect that in a big community. same with Node.js modules for example. i think it’s largely unavoidable. there will be more fragmentation, like when RSC picks up traction. re: docs — fair, my bad for not writing faster
파편화
타당한 말이지만, 거대한 커뮤니티에서는 항상 발견할 수 밖에 없을 겁니다. node.js 모듈도 비슷할 것입니다. 저는 그것들이 피할 수 없는 것이라 생각합니다. RSC가 견인력 얻었었 때처럼 많은 파편화가 있을겁니다.
'문서' - 맞아요. 더 빨리 쓰지 못한 제 잘못입니다.
가족 문제 (Family Affair)
fb
over the past year we’ve started shifting to a model where multiple full-time people on the team don’t work at fb. i expect this to continue, and i personally would like to think we can move to foundation someday. but maybe learn to work that way first
지난 1년 동안 우리는 페이스북에서 일하지 않는 정직원들로 구성된 팀으로 전환하기 시작했습니다. 저는 이것이 지속되기를 바라고, 개인적으로 우리가 언젠가는 재단으로 이동할 수 있을거라 생각합니다. 대신 아마도 그런 식으로 일하는 법을 먼저 배울 것입니다.
마지막으로
- 아직 영어에 서툰 고등학생인지라 번역에 틀린 부분이 있을 수 있습니다. 혹시 발견하셨다면 댓글로 꼭 알려주세요!
