안녕하세요. 구독자님 이번주 뉴스도 봐주셔서 감사합니다 😄
1. 3 Essential React Testing Library Tips for Flawless Tests
https://www.builder.io/blog/3-react-testing-library-tips
이 글에서는 React 테스트 라이브러리를 효과적으로 사용하기 위한 세 가지 팁에 대해 설명합니다.
1. "screen" 객체를 사용해 엘리먼트에 접근하세요: "screen" 객체는 DOM의 요소에 액세스하는 간단하고 직관적인 방법을 제공합니다. 복잡한 선택기가 필요하지 않으며 코드의 가독성을 높여줍니다.
2. 비동기 코드를 처리하려면 "waitFor"를 사용하세요: "waitFor" 함수를 사용하면 어설션을 실행하기 전에 비동기 코드가 완료될 때까지 기다릴 수 있습니다. 이렇게 하면 테스트의 안정성과 정확성을 보장할 수 있습니다.
3. "fireEvent"를 사용하여 사용자 상호작용을 시뮬레이션합니다: "fireEvent" 함수를 사용하면 클릭, 키 누르기, 양식 제출과 같은 사용자 상호 작용을 시뮬레이션할 수 있습니다. 이를 통해 다양한 시나리오에서 컴포넌트의 동작을 쉽게 테스트할 수 있습니다.
2. A Brief History of Reactivity
https://www.builder.io/blog/history-of-reactivity
반응성은 시스템이 상태가 변경되면 자동으로 업데이트하는 기능입니다. 이는 현대 웹 개발의 중요한 측면이며, 특히 React와 같은 프론트엔드 프레임워크의 맥락에서 중요합니다.
Builder.io](http://builder.io/)의 블로그에 있는 "반응성의 역사"라는 글은 웹 개발에서 반응성의 진화에 대한 통찰력 있는 요약을 제공합니다. 이 글에서는 스프레드시트에서 시작된 반응형 웹의 기원을 추적한 다음, 백본(Backbone.js)과 앵귤러(Angular.js) 같은 자바스크립트 프레임워크의 도입과 함께 웹 개발에 처음 구현된 방법을 설명합니다.
그런 다음 가상 DOM을 사용해 반응성을 구현하는 리액트의 개발 과정과 리액트 고유의 접근 방식을 자세히 살펴봅니다. 또한 반응형 프로그래밍의 부상과 Vue.js 및 Svelte와 같은 새로운 프레임워크의 등장으로 인해 React 개발자가 직면한 과제에 대해서도 논의합니다.
전반적으로 이 글은 웹 개발에서 반응성의 역사와 최신 프런트엔드 프레임워크에서 반응성의 중요성에 대한 포괄적인 개요를 제공합니다.
3. Component Driven UI Patterns – Part I
https://blog.codeminer42.com/component-driven-ui-patterns-part-i/
저자는 이 접근 방식이 복잡한 사용자 인터페이스를 만들기 위해 쉽게 결합할 수 있는 재사용 가능한 작은 구성 요소로 인터페이스를 세분화하는 것이라고 설명합니다.
이 글에서는 UI의 확장성, 일관성, 유지보수성 향상 등 이 접근 방식의 이점을 강조합니다. 또한 아토믹 디자인 방법론과 디자인 시스템 사용 등 이 접근법을 사용하여 구현할 수 있는 몇 가지 일반적인 UI 패턴에 대해서도 설명합니다.
4. The End of Front-End Development
https://www.joshwcomeau.com/blog/the-end-of-frontend-development/
이 블로그 게시물에서 저자는 빠르게 진화하는 프론트엔드 개발의 특성과 새로운 기술이 업계에 어떤 영향을 미쳤는지에 대해 설명합니다. 그는 프론트엔드 개발자의 전통적인 역할이 곧 인공지능(AI), 로우코드/노코드 플랫폼, 디자인 투 코드 소프트웨어와 같은 새로운 도구와 기술로 대체될 것이라고 제안합니다. 따라서 프론트엔드 개발자는 이러한 변화에 적응하고 반복적인 코딩 작업에 의존하기보다는 보다 창의적인 문제 해결과 비판적 사고가 필요한 작업으로 초점을 전환해야 합니다. 저자는 프론트엔드 개발자가 이러한 변화를 수용하고 이를 성장과 새로운 가능성을 위한 기회로 삼을 것을 권장합니다.
5. New React docs pretend SPAs don't exist anymore
https://wasp-lang.dev/blog/2023/03/17/new-react-docs-pretend-spas-dont-exist
React의 새로운 문서에서는 새로운 React 프로젝트를 시작할 때 Next.js와 같은 프레임워크를 사용할 것을 권장하며, Vite나 CRA와 같은 번들러를 사용하는 전통적인 방법은 권장하지 않습니다.
그러나 이 접근 방식은 SEO 최적화가 필요하지 않고 원래 React가 설계된 싱글 페이지 앱(SPA)의 사용 사례를 무시합니다.
SSR/SSG가 정적 및 SEO를 고려한 사이트의 주요 문제를 해결했지만, 대시보드형 앱은 여전히 존재하며 그 수가 그 어느 때보다 많습니다.
React가 주요 기능으로 SSR을 강조하는 것은 SSR을 강조하지 않는 다른 솔루션에 대해 강력한 신호를 보내고 있습니다.
프레임워크는 더 많은 의견을 수렴하고 많은 결정을 미리 내려야 하기 때문에 양쪽의 의견을 모두 제시하고 최종 결정은 개발자에게 맡겨야 합니다.
6. How to start a React Project in 2023
https://www.robinwieruch.de/react-starter/
저자는 각 스타터 키트의 장단점을 살펴보고 필요한 기술 수준과 사용 가능한 기능에 주목합니다. 권장되는 스타터 프로젝트는 React with Vite, React with Next, React with Astro입니다.
이 문서에서는 스타터 키트에 대해 설명하는 것 외에도 create-react-app(CRA) 대신 여러 스타터 키트를 권장하는 새로운 React 문서에 대한 React 커뮤니티의 반응에 대해서도 다룹니다. 저자는 새로운 React 문서가 출시된 이유와 권장 스타터 키트에 대한 커뮤니티의 우려에 대한 맥락을 제공합니다.
전반적으로 이 문서는 프로젝트에 가장 적합한 스타터 키트를 선택하기 위한 지침을 찾고 있는 React 개발자에게 유용한 통찰력을 제공합니다. 이 문서는 사용 가능한 다양한 옵션에 대한 포괄적인 개요를 제공하여 개발자가 자신의 필요와 요구 사항에 따라 정보에 입각한 결정을 쉽게 내릴 수 있도록 도와줍니다.
7. Dan Abramov on possible futures for CRA - "client-only doesn’t make sense. way too limiting"
https://twitter.com/dan_abramov/status/1636827365677383700
Create React App의 미래에 대해 생각해보니 클라이언트 전용은 말이 안 된다는 것이 분명했습니다. 너무 제한적이죠.
React가 HTML로 미리 렌더링할 수 있는데 왜 항상 빈 HTML 파일을 생성하는 걸까요? 디스크에 있는 마크다운 파일을 맵()하여 블로그를 만들 수 없는 이유는 무엇일까요?
한동안 저는 이것이 CRA의 다음 반복이 되어야 한다고 생각했습니다. 물론 여전히 Node.js 서버를 사용할 필요는 없지만 빌드 중에 코드를 실행하는 이점을 활용할 수 있어야합니다! 그런 옵션이 없다는 것은 말이되지 않습니다.
CRA는 예전과 비슷하지만 컴포넌트 트리를 정적으로 미리 렌더링하여 HTML이 비어 있지 않도록 할 수 있습니다. 하지만 그 시점부터는 분명히 클라이언트 기능을 사용할 수 있습니다. 우리는 상호작용을 좋아합니다 :)
하지만 라우터와의 통합 없이는 그런 식으로 작동할 수 없습니다. 단일 페이지 이상을 어떻게 미리 렌더링할 수 있을까요? 무엇을 렌더링할지 알 수 없습니다.
좋아, "대부분의 경우 작동하는" 좋은 솔루션으로 파일 기반 라우터를 추가해 보겠습니다. 경로당 HTML + 클라이언트 핸드오프.
빌드 중에 일부 코드를 생성하고 나머지는 클라이언트에서 처리할 수 있는 도구가 생기게 됩니다. 내비게이션은 SPA처럼 느껴집니다.
동적 서버 경로를 하나 추가하고 싶다고 가정해 봅시다. 하지만 그렇게 할 수 없습니다. 서버를 사용하지 못하도록 잠겨 있기 때문입니다.
여기에 문제가 있습니다.
현재 최신 프레임워크(특히 Next.js와 Gatsby)는 이미 이런 방식으로 작동합니다.
100% 정적 + 클라이언트로 시작할 수 있습니다. HTML 생성, 파일 기반 라우팅, SPA 탐색, 실제 클라이언트 코드(원하는 만큼)가 기본입니다.
그러나 파일 대신 DB에서 읽는 것과 같은 동적 경로에 서버를 사용하려는 경우 쉽게 사용할 수 있습니다. 코드 몇 줄만 변경하면 기존 페이지는 정적/클라이언트로 유지됩니다.
프레임워크는 그런 의미에서 종속성이 적습니다.
그래서 저는 이것을 구축하는 것은 Next.js/Gatsby가 이미 제공하는 것의 더 제한된 버전을 구축하는 것일 뿐이라는 것을 깨달았습니다. 이미 하는 것과 똑같은 일을 하지만 더 많은 것을 할 수는 없습니다.
최신 프레임워크는 하이브리드입니다. 하이브리드 프레임워크를 사용하면 SPA를 *더 많이* 구축할 수 있습니다.
React 서버 컴포넌트도 마찬가지입니다. 사람들은 "서버"라고 하면 Node.js를 떠올리지만, 빌드하는 동안 RSC가 실행될 수 있습니다.
사실, Next 13 App Router에서는 이것이 *기본값*입니다. RSC에서 무언가를 fetch()하면 동적 렌더링을 선택하지 않는 한, 빌드 시점에 *실행*됩니다.
우리가 보고 있고, 또 그렇게 하려고 노력하고 있는 변화는 "SPA 작성"에서 "SPA 미작성"으로의 전환이 아닙니다.
"SPA에 종속되는 것"(나중에 빌드 시간이나 서버 측 통합을 추가하기 어려움)에서 "각 페이지에 적합한 모드를 사용하는 것"으로의 변화입니다.
하이브리드 시대.
변화이긴 하지만 대부분 정신적인 변화입니다.
과거: "클라이언트 전용으로 시작하고 빌드 시간이나 서버가 필요할 때 다른 접근 방식으로 다시 작성합니다."
미래: "빌드 시간 + 클라이언트로 시작하되 원하는 대로 분할하고, 원하면 페이지당 서버를 추가합니다."
모든 것이 하이브리드로 수렴함에 따라 기존의 용어는 정말 혼란스러워졌습니다.
- 사람들은 서버를 실행하지 않아도 되기 때문에 "SPA"를 절약하고 싶어합니다.
- 사람들은 페이지 재로딩 없는 탐색을 좋아하기 때문에 "정적"을 무시합니다.
하지만 하이브리드는 이미 이 모든 것을 지원합니다!
8. The Web’s Next Transition
https://www.epicweb.dev/the-webs-next-transition
이 개념 문서에서 저자는 웹 개발 아키텍처의 진화에 대해 논의하고 점진적으로 향상된 단일 페이지 앱(PESPA)이 다중 페이지 앱(MPA)의 단순성과 단일 페이지 앱(SPA)의 기능을 결합하여 두 가지의 장점을 모두 제공한다고 주장합니다. 이 문서에서는 코드 중복, 런타임 성능, 개발자 경험 등 이전 아키텍처의 한계와 문제점, 그리고 PESPA가 이러한 문제를 해결하는 방법에 대해 설명합니다.
저자는 PESPA 원칙을 완전히 수용하고 개발자가 더 나은 경험을 더 빠르게 구축할 수 있도록 지원하는 웹 프레임워크로서 Remix를 강조합니다. Remix는 네트워크를 가로지르는 다리 역할을 하며 라우팅, 데이터 가져오기, 변이, UI 피드백을 처리하여 보류 중인 상태와 낙관적인 UI를 구현합니다. 중첩 라우팅을 통해 PESPA는 더 나은 코드 구성과 더 세분화된 코드 분할을 제공하여 더 빠르고 효율적인 앱을 제공합니다.
이 문서는 전반적으로 웹 개발 아키텍처의 역사에 대한 포괄적인 개요를 제공하며, 이전 아키텍처의 많은 문제를 제거하면서 개발자에게 더 단순한 멘탈 모델과 더 나은 사용자 경험을 제공하는 PESPA가 앞으로 나아갈 길이라고 주장합니다.
9. Fully Typed Web Apps
https://www.epicweb.dev/fully-typed-web-apps
이 문서에서는 유형 가드 및 어설션 함수 사용, Prisma와 같은 도구를 사용한 유형 생성, 규칙/구성을 사용하여 예상 유형을 TypeScript에 알리는 방법 등 웹 애플리케이션에서 유형 안전성을 달성하는 방법에 대해 설명합니다. 저자는 경계를 넘나드는 유형 안전성의 가치를 강조하고 이를 달성하는 방법에 대한 예를 제공합니다.
이 문서에서는 경계를 넘나드는 유형 안전성을 보장하는 데 중점을 두고 웹 애플리케이션에서 유형 안전을 달성하는 다양한 방법을 살펴봅니다. 저자는 타입 가드와 어설션 함수를 사용하여 폼의 폼데이터를 처리하는 방법과 Prisma와 같은 도구를 사용하여 데이터베이스 상호 작용을 위한 타입을 생성하는 방법에 대해 설명합니다. 또한 TypeScript에 예상되는 유형을 알리기 위한 규칙과 구성의 중요성을 강조하고 Remix 프레임워크를 사용한 예제를 제공합니다. 전반적으로 이 문서는 웹 개발에서 유형 안전성의 가치를 강조하고 이를 달성하는 방법에 대한 실용적인 예제를 제공합니다.
10. Full Stack Components
https://www.epicweb.dev/full-stack-components
이 튜토리얼에서는 `useFetcher`와 `spin-delay`를 사용하여 서버에서 데이터를 가져오고 로딩하는 동안 스피너를 표시하는 고객 콤보박스를 만드는 방법을 보여드립니다. 이 튜토리얼은 또한 컴포넌트와 낙관적 UI에 Remix를 사용할 때의 이점을 강조합니다.
먼저 전체 페이지 경로뿐만 아니라 개별 컴포넌트에 대해서도 Remix를 사용하여 UI와 백엔드 코드를 코로케이션하는 방법을 설명합니다. 이 접근 방식은 복잡한 컴포넌트 생성에 수반되는 간접성을 줄여 코드를 간소화합니다.
다음으로 저자는 `useFetcher`를 사용하여 서버에서 데이터를 가져와 고객 콤보박스에 표시하는 방법을 보여줍니다. 로딩 상태를 처리하고 데이터를 가져오는 동안 스피너를 표시하는 방법을 보여줍니다. 또한 데이터가 빠르게 로드될 때 스피너가 깜박이는 것을 방지하기 위해 '스핀 지연'을 소개합니다.
저자는 변경이 수행될 때 페이지의 데이터를 자동으로 재검증하는 기능을 포함하여 컴포넌트에 Remix를 사용하면 얻을 수 있는 이점을 강조하면서 튜토리얼을 마무리합니다. 또한 낙관적 UI 사용의 장점을 언급하며 독자들이 다음 강연에서 이에 대해 자세히 알아볼 것을 권장합니다.
전반적으로 이 문서는 Remix를 사용하여 UI와 백엔드 코드를 배치하는 컴포넌트를 만드는 방법에 대한 포괄적인 튜토리얼을 제공하며, 이 접근 방식의 강력함과 단순성을 보여줍니다.
11. Dan Abramov - "most modern React frameworks don’t require a Node.js server anymore. they just let you add one if you need it."
https://twitter.com/dan_abramov/status/1636716018973257728
대부분의 최신 React 프레임워크는 더 이상 Node.js 서버를 필요로 하지 않습니다. 필요한 경우 서버를 추가할 수 있습니다.
https://twitter.com/timneutkens/status/1636693508223270912
We've been working on improving `next export`
◆ App Router compatible
◆ Server Components compatible
◆ Route Handlers compatible
◆ Built-in to `next build`
◆ Ensures development matches static export
Shipped on canary, stable soon! https://app-router-export.vercel.app
12 . Dan Abramov - Next.js example - purely client-side SPA (no Node.js server, 100% static bundle)
https://twitter.com/dan_abramov/status/1636886736784457734
많은 사람들이 / stuff/:id와 같은 동적 라우팅을 사용하면서 Next.js를 사용하여 순전히 클라이언트 측 SPA(Node.js 서버 없음, 100% 정적 번들)를 만드는 방법을 묻고 있습니다.
Next.js 문서에서 명확하게 설명되어 있지 않아서 예제를 만들었습니다.
https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b333434ef6
README에서 언급했듯이 주요 주의 사항은 Next.js가 *경로당 * HTML 페이지를 생성한다는 것입니다. 정적으로 호스팅하고 호스트가 JS로 작성되지 않은 경우 정적 호스트에 대한 재작성 규칙 목록을 생성해야합니다. 이상적으로 Next.js는 Nginx, Apache 등에 대한 자동 생성을 추가해야합니다.
그러나 이 주의 사항은 Next.js의 결함이 아니라 오히려 대부분의 SPA가 하는 방식으로 SPA 배포의 결함을 *수정*합니다.
모든 경로에는 고유한 HTML 파일이 있으므로 Next.js는 해당 페이지에서 사용되는 청크에 대한 <script> 태그만 넣습니다. 그리고 일부 콘텐츠를 미리 생성할 수 있습니다.
공통 설정에 대한 몇 가지 템플릿을 만들어야 할 것 같아요. 각 권장 프레임워크에 포팅된 동일한 작은 앱일 수도 있고, Node.js 서버용과 서버가 전혀 없는 예제를 따로 만들어서 공통 설정 방법을 보여주고 서로의 패턴을 비교할 수도 있죠.
개츠비에서 동일한 작업을 수행하는 방법은 다음과 같습니다( @bradwestfall 팁 주셔서 감사합니다!): https://gatsbyjs.com/docs/how-to/routing/client-only-routes-and-user-authentication/ 또한 동일한 경로 재작성 트릭이 필요합니다(하지만 일부 제공업체는 이 작업을 자동으로 수행합니다).
13. Map of React API
https://julesblom.com/writing/map-of-react-api
14. React PR - Suspend commit without blocking render
https://github.com/facebook/react/pull/26398
이는 렌더러(React DOM, React Native)에 새로운 기능을 추가합니다. 트리가 준비될 때까지 트리가 표시되지 않도록 하고, 필요한 경우 폴백을 표시하지만 그 동안 React 컴포넌트가 평가되는 것을 차단하지 않습니다.
구체적인 예는 CSS 로딩입니다: React DOM은 스타일시트가 로드될 때까지 커밋이 적용되지 않도록 차단할 수 있습니다. 이를 통해 CSS를 비동기적으로 로드하는 동시에 스타일이 지정되지 않은 콘텐츠가 갑자기 표시되는 것을 방지할 수 있습니다. 이미지와 글꼴은 다른 사용 사례 중 일부입니다.
이를 "커밋 단계에 대한 서스펜스"라고 생각할 수 있습니다. 전통적인 서스펜스, 즉 사용 시에는 렌더링 단계에서 차단됩니다: React는 데이터를 사용할 수 있을 때까지 렌더링을 진행할 수 없습니다. 하지만 스타일시트와 같은 것의 경우 컴포넌트를 평가하기 위해 CSS가 필요하지 않습니다. 트리가 커밋되기 전에 로드하기만 하면 됩니다. React는 부작용과 변이를 버퍼링하기 때문에 스타일시트가 백그라운드에서 로드되는 동안 병렬로 작업을 수행할 수 있습니다.
일반 Suspense와 마찬가지로, "suspensey" 스타일시트나 이미지가 아직 로드되지 않은 경우 가장 가까운 Suspense 폴백이 트리거됩니다. 하지만 현재로서는 startTransition과 같이 긴급하지 않은 업데이트에 대해서만 이 작업을 수행합니다. 긴급한 업데이트 중에 서스펜스 리소스를 렌더링하면 오늘의 동작으로 되돌아갑니다. (향후 긴급한 업데이트 중에 커밋을 일시 중단하는 방법을 추가할 수도 있고 추가하지 않을 수도 있습니다.)
이번 PR에서는 호스트 구성에 추가된 새로운 메서드를 통해 재조정자에서 이 기능을 구현했습니다. 이 기능을 시연하는 테스트를 작성하기 위해 내부 React "no-op" 렌더러를 사용했습니다. 아직 Suspensey CSS, 이미지 등을 React DOM에 구현하지는 못했습니다. 후속 PR에서 @gnoff와 함께 작업할 예정입니다.
https://twitter.com/acdlite/status/1637102880850059264
트랜지션 중 또는 서스펜스 경계 내에서만 발생합니다. 그리고 타임아웃이 내장되어 있습니다. 동작이 변경되는 것을 눈치채지 못하도록 마술처럼 덜 짜증나게 하는 것입니다.
img loading=lazy로 옵트아웃할 수 있습니다.
15. React PR - Remove layout effect warning on the server
https://github.com/facebook/react/pull/26395
이 PR은 안타깝게도 서버에서 레이아웃 효과를 사용할 때 발생하는 경고를 제거합니다:
사용 레이아웃 효과는 서버 렌더러의 출력 형식으로 인코딩할 수 없기 때문에 서버에서 아무 작업도 수행하지 않습니다. 이로 인해 수화되지 않은 초기 UI와 의도한 UI 간에 불일치가 발생합니다. 이를 방지하려면 클라이언트에서만 렌더링하는 컴포넌트에서만 사용LayoutEffect를 사용해야 합니다. 일반적인 수정 사항은 https://reactjs.org/link/uselayouteffect-ssr 을 참조하세요.
변경하는 이유
실제로 사용자들은 이 경고를 무시할 뿐만 아니라, 서버에서 이 경고를 수정하는 대신 useLayoutEffect 훅을 전환하여 이 경고를 우회하는 훅을 생성하고 있습니다. 이 싸움에서 진 것 같으니 적어도 사용자가 더 이상 방향 지정 훅을 사용할 필요가 없도록 경고를 제거해 봅시다. 실제로 문제가 된다면 개발 단계에서 첫 번째 로드 시 잘못된 콘텐츠가 깜박이는 등의 문제가 발생해야 합니다.
16. Signals vs. Observables, what's all the fuss about?
https://www.builder.io/blog/signals-vs-observables
"신호와 옵저버블"은 신호와 옵저버블이라는 두 가지 프로그래밍 개념을 비교하는 블로그 게시물입니다. 둘 다 소프트웨어 개발에서 비동기 이벤트를 처리하는 데 사용되지만 구현과 사용 사례에서 주요 차이점이 있습니다.
신호는 가볍고 메모리 효율적이며 이해하기 쉽습니다. 신호는 여러 가입자가 수신하고 수신할 수 있는 이벤트인 간단한 이벤트 이미터 패턴을 기반으로 합니다. 신호는 종속성이 적은 소규모 애플리케이션에 이상적입니다.
반면에 옵저버블은 더 강력하고 유연하여 개발자가 데이터 스트림을 조작하고 복잡한 연산을 구성할 수 있습니다. 옵저버는 반응형 프로그래밍 패러다임을 기반으로 하며, 옵저버 패턴을 활용합니다. 옵저버는 규모가 크고 복잡한 애플리케이션에 더 적합하지만, 파악하기 어렵고 올바르게 사용하지 않으면 성능에 영향을 미칠 수 있습니다.
결론적으로, 시그널과 옵저버 모두 장단점이 있으며, 개발 중인 애플리케이션의 특정 요구 사항과 복잡성에 따라 선택이 달라집니다.
17. 선언적인 코드 작성하기
https://toss.tech/article/frontend-declarative-code
이 문서에서는 수정하기 쉬운 선언적 코드 작성의 중요성에 대해 설명합니다. 선언적 코드가 항상 최선의 해결책은 아니지만, 수정하기 쉬운 코드에 우선순위를 두는 것이 중요합니다. 이를 위해 Toss는 `useOverlay`, `ImpressionArea`, `LoggingClick`과 같은 선언적 라이브러리를 사용합니다.
선언적 코드의 한 예로 등록 로직을 하나의 컴포넌트로 추상화하여 선언적으로 만든 `SignUpForm` 컴포넌트를 들 수 있습니다. 이렇게 하면 화면마다 각 양식을 복제할 필요가 없으므로 개발이 더 효율적입니다. 또한 폼의 변경 사항은 해당 폼이 사용되는 모든 화면에 반영됩니다. 하지만 화면마다 'SignUpForm'이 조금씩 다른 경우, 이를 지나치게 일반화하면 복잡성이 증가할 수 있습니다.
BottomSheet, Dialog, Toast와 같이 화면 오버레이가 필요한 경우, Toss는 `useOverlay` Hook을 사용하여 동작을 추상화합니다. 이를 통해 코드가 단순화되고 모든 오버레이 화면을 여는 데 사용할 수 있는 단일 함수를 만들 수 있습니다.
오버레이 외에도 Toss는 `ImpressionArea` 컴포넌트를 사용하여 사용자 행동을 추적합니다. 이 컴포넌트는 특정 요소가 화면에 표시되는지 여부를 기록합니다. 이는 사용자가 요소와 상호작용을 해야만 표시되는 것으로 간주되는 경우에 특히 유용합니다.
마지막으로, 토스는 `LoggingClick` 컴포넌트를 사용하여 버튼에 대한 사용자 행동을 추적합니다. 이 컴포넌트는 특정 버튼을 클릭한 사용자 수를 기록하여 데이터 기반 의사 결정에 유용합니다.
전반적으로 선언적 라이브러리를 사용하면 사용자에게 높은 수준의 기능을 제공하면서도 수정 및 유지 관리가 쉬운 코드를 작성할 수 있습니다.
이번주 준비한 것은 여기까지입니다 😄
읽어주셔서 감사합니다 😉
댓글
의견을 남겨주세요