feconf

React 바깥의 프론트엔드

2023년의 프론트엔드 개발은 사실상 React로 천하 통일되었습니다. 그런데, 우리는 정말 각자의 문제를 푸는 데에 React가 필요해서, 혹은 React가 가장 적절한 도구라서 사용하고 있을까요? 프론트엔드 애플리케이션을 구성하기 위한 다양한 선택지들을 살펴보고, React 안팎의 프론트엔드 생태계를 둘러보면서, 각자의 문제를 푸는 데에 가장 적절한 도구를 찾아가 보는 시간을 가져보려 합니다.

React가 등장하기까지

1. MPA, jquery에서 html을 그리기에는 복잡한 연산이 있었음
2. MVC, MVVM등의 패턴을 도입해 UI/데이터를 사용자에 반응하려고 많은 시도가 있었음(ex. Anguler)
3. React는 UI를 선언전 인터페이스로 작성해 로직 단순화 ,VDOM을 활용해 실제 dom의 접근을 최소화해 성능을 개선함
4. 하지만 React로 넘어오면서 JS 번들 크기 증가, DOM 조작의 번거로움. SSR시 JS 서버 강제

최초 화면을 어떻게 그릴지

• 서버에서 그리기
  - 서버 로직까지 고려해야함, 상태를 전달하기 힘듦
• 서버에서 빈껍데기만 그리고 , 클라이언트에서 그리기
  -
• 서버와 클라이언트 간에 공유 가능한 코드로 그리기
  - hygration 과정이 필요해 약간의 시간이 걸릴 수 있음

SSR 환경(Node.js) 메모리 누수 디버깅 가이드

박지혜 · 토스플레이스

SSR 도입하는 회사들이 꽤 많아지다 보니 Node.js 환경에서 메모리 누수(memory leak)를 디버깅해야 하는 상황이 종종 발생하는 것 같아요. 크롬 브라우저의 메모리 프로파일링 기능들에 대한 설명과 메모리릭을 찾아가는 과정을 통해 메모리릭이 디버깅에 막막함을 덜어드리고자 합니다.

https://flyingsquirrel.medium.com/ssr-memory-leak-%EB%94%94%EB%B2%84%EA%B9%85%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95-ce3cf41c107c

1.메모리누수

• 실제로는 필요하지않은데. 메모리를 계속 차지하고 있는 현상
• server side 모니터링 (Datadog)
• client side 모니터링 ( ..?)

메모리누수 해결법

1. 힙메모리를 늘린다

• 늘려도 결국 죽음 V8 엔진은 Mark and sweep 알고리즘인데 객체는 heap memory를 타는데 v8이 old greneration을 채워가면서 결국 죽는다
  --max-old-space-size는 old generation 사이즈만 늘리지만 영역만 늘어나지 실제적인 해결법은 아님
  -- 메모리를 누수를 일으키는 요인들
• 전역변수
• 해제되지않은 타이머 clearTimeout등
• 클로저

2. 메모리누수 디버깅 하는 방법

• node --inspect index.js

몇 천 페이지의 유저 가이드를 새로 만들며

몇 천 페이지의 유저 가이드를 새로 만들며 이찬희 · AB180 "처음에는 쉽다고 생각했는데..." "'유저 가이드'에 이렇게까지 많은 엔지니어링 포인트가 숨어있을 줄은 몰랐지..." 몇천 페이지의 콘텐츠를 제공하는 유저 가이드를 처음부터 새로 만들며 만난 엔지니어링 문제들을 이야기합니다. 웹 접근성의 구현, 빌드 속도의 향상, Next.js App Router 등의 얼리 스테이지 기술 사용 사례를 짚어봅니다. 이를 통해 제품의 특성을 파악하고 복잡도를 제어하며 프론트엔드 개발자로서 성장하는 방법을 함께 이야기하고자 합니다.

https://hiddenest.dev/accessible-accordion

https://help.airbridge.io/ko/guides/getting-started-with-airbridge

1. 유저가이드
   기존에는 Zendesk 서비스로 운영 , nextjs app route로 구현으로 마추진 문제점들

• 아코디언 이슈
  comman +f로 특정 냉요을 검색했을때 , 자동으로 아코디언이 펄쳐졌으면 좋겠습니다. ( 참고로, 경쟁사에는 그런 기능이 있다고함) hidden="until-found" beforematch event , 요소는 숨겨져 있지만 렌더링 상태는 유지하는 기술, 하지만 제대로 동작하지않음

1. [hidden = "util-found"]는 올바른 속성이지만 최신 스펙이기에 리액트에 반영되지 않아 잘못된 값으로 인식.
   동작한다
   html은 대소문자를 가리지않고 React Dom은 정의된 소문자 로 시작하는 속성만 검증. dom에 beforematch만 추가하면 동작할것
   로 해결함

• 가이드 이전하며 생긴 일
  CMS 보일러플레이트들은 SSG 사용 왜냐하면 콘텐츠 변경 자주있지않고. 초기 로딩속도 SEO 향상이 주 목적 수정이 잦아지면 변경 페이지만 재생성하는 ISR을 도입한다.
  가이드가 늘어날수록 빌드 속도가 느려짐 8분 이상 소요됨 ISR만으로 어느정도 해결했지만 근본적으로 해결하지 못한부분은 유저 가이드의 사이드바가 문제였음 App route가 Page Route보다 속도가 3배빠름 페이지 단위만 고민했지만 페이지 내의 동적 정적인 기능들이 있다보니 각 태그별로 기능을 고려해 페이지를 구성해보자로 생각을 전환함, 그래서 모든 페이지를 ISR 구현하되 각 컴포넌트마다 재생성 시간을 조절했다,해당 방식으로 빌드속도 8배 개선

1. 모든 페이지에 한버은 접속해야 캐시가 돌지않나요

• 웹 크롤러는 사이트맵에 정의된 모든 페이지에 1회 이상 방문

1. 캐시 dynamic 이슈 ( 쿠키때문에 )
   문제 해결에 대한 고민 이슈
   3시간 동안 레퍼런스를 검색함

이벤트 기반 웹뷰 프레임워크 설계와 플러그인 생태계 만들기 원지혁 · 당근

웹뷰 프레임워크 Stackflow를 만들게 된 핵심 문제를 소개하고, Stackflow의 기초적인 이벤트 기반 설계로의 리팩토링과 그것을 활용한 플러그인 인터페이스를 소개합니다. 그리고 플러그인을 통한 확장 가능한 설계로 사내 개발 생태계를 구축한 사례 등 프레임워크를 만들며 얻은 핵심 설계 노하우들을 공개합니다. (https://github.com/daangn/stackflow)

1. stackflow 라이브러리 만드는 과정
   화면 전화 효과 만들기

. History API로 구현해보자는 생각을 가짐
이전 페이지를 기억하지못해 react에서 history 상태를 관리해서 어떻게든 구현했음
react-router-dom에 의존하면서 발생한 이슈는

• 의존성이 강해 테스트를 할 수 없어 이슈 대응하기 어려웠음
• 상태 동기화에 버그가 발생하기 쉬운 코드가 만들어짐
• 특정 기술 스택에 종속됨
• 확장하기 어려워 useEffect useCallBack등의 활용성이 떨어짐

. 리팩토링
해당 문제점을 개선하기 위한 구조 논의를 가짐

• Transition, Navigation, URL이 본질이 아닌 Stack으로 중점을 바꿈
• Stack을 만들기 위한 이벤트 기반으로 어떤것이 있는지 찾아봄
• Stack을 조작하는 함수를 생성하고 react18의 useSync와 함께 동기화를 해 해결함

. 확장성
하지만 유저의 특정한 상황으로 버그가 발생하고있었음

• 상상력을 펼칠 수 있도록 미리 재료만 준비하기

크로스 플랫폼 디자인 시스템, 1.5년의 기록.

당근마켓 디자인 시스템 팀이 걸어온 길을 소개합니다. 디자인 시스템의 설계와 구현 접근을 공유하며, 이 과정에서 겪은 실패와 그로부터 얻은 교훈을 함께 나눕니다.

1. 디자인시스템이 추구하는 방향에 따라 다름
   chakra는 유연함을 위해 코드가 길어짐 (유연성 시스템)
   Adobe 제품군은 코드가 짧지만 정해져있음 (제품 언어)
2. 모든 제품을 커버하는 범용 디자인 시스템은 불가능, 어떤 제품 언어를 만들더라도 항상 반복되는 방법론은 존재한다, 디자인 의사결정의 집합을 제품 디자인에 관련된 모든 영역에 효과적으로 동기화 하는 시스템
3. Atomic 디자인이 혼란스러운 이유
   형태, 기능 등의 정의가 커뮤니케이션에 따라 다르기 때문
4. 의사소통의 순환참조
   서로의 의존성으로 커뮤케이션붕괴가 발생함