React 19 출시는 더 늦어질 것이다
2024. 7. 3.
2주치를 만들려고 기사를 모두 봤더니 2주동안 너무 많은 소식이 쏟아졌네요.. 최대한 담았습니다.
React 19 출시는 더 늦어질 것이다
심윤섭: React 19에서 클라이언트 측 Suspense가 waterfall형식으로 진행된다는 것에 대한 토론이 있었고, 이 동작이 적절하지 않고, 더 많은 피드백과 수정을 거치고 React 19를 출시할 것이라는 소식입니다. 이전에 React-Query와 RSC를 같이 쓰기(React 18)에서도 나온 Server actions도 waterfall형식으로 진행되서 많은 생각이 들기도 했었던 것이 생각나네요. 이전에도 나온 React 18에서의 불만과 같이, 안정된 상태로 출시한다면 좋은 기능들이라고 생각해서 제대로 만들었으면 좋겠네요.
김대관: React 19에 대한 소식은 위의 벨로그 번역 글을 통해 처음 알게 되었는데, React 19로 오면서 waterFall 방식으로 진행한다는 소식은 프론트엔드 개발자들 사이에서 매우 뜨거운 감자였습니다. 이러한 이슈를 통해 많은 개발자들의 피드백이 이어지면서 React 19에 관심이 집중되었습니다. 물론 React팀이 이번 사건으로 많은 피드백을 받아 잘 수정하겠지만, 실제로 어떻게 클라이언트에서의 Suspense 로직이 흘러갈지는 모릅니다(예시로 알고리즘 제안도 있었습니다). 그래서 이러한 이슈와 기술의 변화를 잘 주시해야 합니다.
React와 SOLID 원칙
심윤섭: 길어서 여러 문단으로 나누기로 했습니다. :)
이전에 카카오 엔터테이먼트 기술 블로그의 프론트엔드와 SOLID 원칙과 비슷하지만, React에 국한해서 SOLID 원칙을 어느 곳에서 사용해볼 수 있는지 생각해볼 수 있는 글입니다. 카카오 엔터테이먼트 기술 블로그의 글은 UI 출력과 컴포넌트 관점으로 살펴봤다면, 이 글은 Custom Hook과 React의 기본 hooks에 집중해서 원칙이 어떻게 적용될까 살펴보는 과정을 거칩니다. 그동안 프론트엔드가 거쳐오면서 기존의 패턴의 적용 방법에 대해 고민해보고, 신규 패턴에 대해 어떻게 다뤄야 할지에 대한 고민들이 많이 거치게 되었습니다. 이에 대해서는 많은 주장과, 많은 비판들이 따르기 마련입니다.
객체지향의 대표인 이 SOLID 원칙 또한 그렇죠. 원칙을 따르게 되면 시간이 매우 오래걸릴 뿐더러, 원칙의 제한때문에 간단하게 짜일 코드가 어렵게 돌아가는 경우가 있습니다. 하지만 원칙이 아예 없다면, 코드가 중구난방이 되어서 모두가 이 코드는 레거시야 하고 건들 생각조차 못하게 되겠죠. 개인적으로는 원칙이 있는 이유는 우리가 소통하는 언어를 동일하게 가져가기 위해서라고 생각합니다. 원칙에서 말하는 용어를 바탕으로 우리가 코드를 짜는 방식을 어떻게 결정하느냐에 따라 갈리는 것이죠.
나중에 따로 쓰려고 했던 토스 모닥불의 OOP FP 논쟁에서도 보였듯이, FP와 OOP가 반대되는 개념이 아니라, 공존할 수 있는 개념이라고 했던 것과 비슷한 관점으로 바라봤으면 좋겠습니다. FP와 OOP가 다른 말로 같은 개념을 말하고 있는 것도 있듯이, 두 개념은 방향은 비슷하지만 다르게 해석되어서 원칙이 된 것이라고 생각합니다. 그런 의미에서 한 원칙을 모두 항상 따를 필요는 없고, 관점을 늘리기 위해서 이런 해석(원칙)의 해석이 있다라는 식으로 보면 좋습니다.
글 내용은 함수가 여러 동작 하게 하지 마라 / 추상화를 견고하게 만들어라에서 벗어나지 않습니다. 그래도 이런 관점도 있다는 생각을 나중에도 떠올리기 위해 보셨으면 좋겠습니다. 개인적으로 모두 추상화 과정에서 이루어지는 것이라 추상화에 대한 접근 방식을 팀에서 정하면 좋겠다는 생각도 드네요. 😅
Slack의 AI기반 라이브러리 교체
심윤섭: RTL은 블랙박스 테스팅 접근 방식을 잘 적용하기 쉽게, 그리고 테스트를 작성하기 쉽게 만들었습니다. 그리고 React 16이 나오게 된 이후 Enzyme의 지원이 점점 낮아졌습니다. Slack에서는 모든 테스트 코드를 AST로 분석해서 AI 기반으로 라이브러리 교체하는 방식을 소개합니다. 이후에 다른 패러다임을 적용한 라이브러리로 교체할 때 획기적으로 단축해주지는 않지만 새로운 접근방식이고 주목해볼만한 사례라고 생각합니다.
React 컴파일러의 이해
심윤섭: React 컴파일러를 이해하기 전에 트랜스파일러와 컴파일러의 개념, React의 기본 개념을 설명하고 React 컴파일러의 동작 방식을 설명합니다. 간단한 개념과 메모이제이션을 위한 추적 방식의 기본만 설명하기 때문에, 컴파일러의 내부 동작과 적용된 이론을 자세하게 보려면 개발자의 블로그 글을 보시길 바랍니다(특히 React 컴파일러의 타입 시스템을 보시길 바랍니다).
React의 미래?
심윤섭: React의 컴포넌트, 가상돔, 라이브러리 생태계의 개념은 좋든 싫든 프론트엔드의 변화를 가져왔습니다. 현재 React는 UI 로직에만 관여했던 라이브러리를 생태계에서 신경 썼던 문제 상황(주로 UI)을 React 내로 가져오고 있습니다. 그와 같이 메타 프레임워크와의 협력으로 작게는 인스턴스, 넓게는 인프라까지 다룰 수 있도록 한다고 생각합니다. React에 반감을 가진 다른 프레임워크가 갑자기 떠오르거나, 아니면 React의 생태계 로직을 React 로직 내부로 들여올 수 있을 것인지 지켜봐야 할 것 같습니다. 번외로 React Native에서도 메타 프레임워크를 더욱 권장하고 있어서, 메타 프레임워크의 방향도 신경써야 할 것 같네요(프레임워크를 사용하여 React Native 구축).
모노레포에서의 TypeScript
심윤섭: 모노레포 식으로 세팅하면서, 다른 패키지나 앱에서 타입을 가져오는 것은 보통 tsconfig.json의 reference를 사용하는 것이 일반적이지만, 그럼에도 유형을 가져오거나 타입 생성, 다른 도구와 통합에 어려움을 겪기도 합니다. 이를 해결하기 위해 여러가지 방식을 제안합니다. 주로 라이브러리를 활용하는 방식이지만, package.json을 통해서 접근하는 방식이 눈에 띄네요.
CSS hack과 새로운 친구들
첫번째 글은 CSS Nesting 기능을 통해 BEM modifier를 다른 방식으로 쉽게 표현하는 방식을 소개합니다. 물론 &뒤에 modifier까지 모두 붙인 class를 붙이는 것과 호불호가 갈릴 수도 있겠네요. 그리고 2번째 글은 CSS에 if 함수가 논의 될 예정이라는 소식에 대한 글이고, 3번째 글은 브라우저까지 오기 전까지 그동안 조건부 값을 어떻게 사용하였는지에 대해 여러가지 방법을 제시하는 글입니다. 함수로 나온 만큼 모던 브라우저가 아닌 브라우저의 폴리필이 어떻게 진행될지도 궁금해지네요. 끝 2개의 글은 CSS 위주의 모던 브라우저에서 쓸 수 있는 속성들을 소개해주는 글들입니다. 많이 유명해진 Container Query와 @property, CSS nesting이 있지만 block에서의 가운데 정렬과 safe flexbox가 눈에 띄네요.
State of JS 2023
JS의 신기술이 무엇이 있는지, 그에 대한 다른 개발자들의 생각은 어떨까에 대해 볼 수 있는 설문결과입니다.
Queue 설명 시각화
재밌는 애니메이션과 함께 Queue의 종류를 이해할 수 있도록 돕습니다. SSR이 중요시되는 지금 중요한 개념이라고 생각되네요.
React 동작 방식 시각화
React 내부 딥 다이브 시리즈의 저자가 시각화 다이어그램 사이트를 만들었네요. 더 쉽게 동작 방식을 이해할 수 있을 것 같네요.
INP가 말하고자 하는 것
메인스레드를 block하지 않도록 이벤트 실행 시에 생기는 긴 작업을 쪼개는 것을 해달라는 INP에 대한 분석입니다. 이 과정에서 await-interaction-response를 사용하거나 useTransition을 쓰면 해결할 수 있다는 해결책과 같이요.
자바스크립트의 무작위성
Math.random은 crypto.getRandomValues보다 불안전한 난수를 사용한다고 하지만, 공격자 입장이 아닌 사용자 입장에서 난수 생성은 느낌일 가능성이 높습니다. 그래서 저자는 두가지 방식을 통해 난수를 생성하고 연속적으로 생성될 확률을 체크하고, 느낌적인 면에서는 크게 다르지 않다는 생각을 말합니다.