Overview 리액트를 사용해서 프론트엔드 웹 애플리케이션을 개발하는 경우, 많은 곳에서 Atomic Design Pattern을 사용하게 됩니다. 컴포넌트를 하나의 함수로 보고, 클린 아키텍쳐의 관점에서 재사용 가능한 컴포넌트들을 그 기능과 구성에 따라 구조화 하여 사용하는 이 패턴은 어느샌가 프론트엔드 아키텍쳐를 이루는 하나의 교과서처럼 되어 알려지고 있습니다. 하지만 이 Atomic Design Pattern을 실제 애플리케이션에 적용해서 개발하다보면 생각보다 많은 부분들이 "추상적"이고 "주관적"이라는 느낌을 받는 경우가 많습니다. 오히려 적용한 이후에 코드가 더 관리가 어려워지고 지저분해지는 경우도 많은데, 이는 Atomic Design Pattern이 처음 등장할 때 그 사용처가 "Desig..

위 아티클은 React 17버전(17.0.1) 기준으로 작성되었습니다. 17버전 이전(16버전 이하)에서는 조금 다르게 동작할 수 있으며, 이 차이점에 대해서는 이어지는 시리즈(2)에서 다룰 예정입니다. Overview 리액트로 웹 애플리케이션을 개발하다보면 사용자와 유연하게 상호작용하는 컴포넌트를 만들기 위해 onClick, onChange등의 이벤트 핸들러(Eventhandler)를 사용해야 합니다. 크로스 브라우저 대응 등을 위해 리액트 자체적으로 제공하는 안정성 있는 이벤트 핸들링 시스템 덕분에 대부분의 경우 핸들러를 붙이기 원하는 컴포넌트에 다음과 같은 형태로 이벤트 핸들러를 넣어주면 되지만, 컴포넌트들이 복잡하게 상호작용하고 있는 대형 애플리케이션의 경우, 때로는 이 이벤트 핸들러들로 인해 의..

위 포스팅은 이전 포스트의 내용을 이어서 진행합니다. [Webpack] Config file & Asset Modules [Webpack] Introduction & Setup [Webpack] Loaders [Webpack] Plugins Code Splitting 애플리케이션을 번들링 할 때, 적절한 단위로 번들을 쪼개는 것은 애플리케이션 성능에 있어서 중요한 요소 중 하나입니다. 규모가 크고 많은 페이지를 가지고 있는 애플리케이션이더라도 사용자의 화면에 보이는 페이지는 하나이기 때문에 사용자가 보지 않을 수도 있는 페이지까지 함께 가져오는 것은 잠재적인 대역폭 낭비이고, 초기 렌더링 시간을 잡아먹게 됩니다. 따라서 적절한 단위로 번들을 나누어서(Code Splitting) 빌드하는 것이 중요합니다...

Overview 4월 회고를 쓰려고 보니 5월이 다 지나가 버렸다. 별 수 없이 4~5월 회고를 쓰기 위해 키워드를 정리하는데 생각보다 이것저것 배운 게 많은 것 같아서 회고할 타이밍을 굉장히 잘 잡았다는 생각이 들었다. 초당 수만 ~ 수십만 건의 대용량 트래픽이 발생하는 애플리케이션의 최전선에서 여러 버저닝을 관리하고 예측하기 어려운 에러들을 핸들링하는 기회가 모든 개발자들에게 찾아오는 건 아닐 것 같은데, 이런 경험을 쌓아나간 것 같아서 감사한 마음이 들었다. FrontEnd Service With Million Traffics 900만명 가까운 사용자가 접속하는 웹 프로젝트를 맡아 개발하는 데에는 참 많은 책임이 따른다는 걸 배웠다. 이전에는 TF에서 맡은 컴포넌트만 몇 개 만든 다음에 QA 돌려보..

Kent. C Dodds의 'One simple trick to optimize React re-renders'를 Reference 하였습니다. Overview React를 사용해서 Web Application을 만들 때, 퍼포먼스의 향상하기 위하여 여러 가지 렌더링 최적화 기법들을 시도합니다. 대표적인 방법이 React.Memo를 사용하여 불필요한 리렌더링을 방지하기, 상태(State)를 업데이트 하는 로직은 최대한 하위 컴포넌트로 내리기등이 있습니다. 이번 포스팅에서는 자주 사용되고, 또 자주 접할 수 있는 위 두 가지 최적화 방법 이외에도 JSX가 가지고 있는 특성을 사용해서 불필요한 리 렌더링을 방지하는 방법을 살펴보려고 합니다. JSX JSX는 Javascript의 확장 문법으로, React에서..

Overview Web Programming 여러 분야의 개발을 동시에 하면서 항상 그래 왔지만 유난히도 '참 가야 할 길이 멀구나' 싶은 생각이 들었던 한 주였다. 우선 프런트엔드 쪽에서는 그동안 개발했던 웹 랜딩페이지(+모바일 대응) 보다는 철저히 모바일을 위한, 데스크톱이 아닌 디바이스의 환경에 최적화된 웹뷰 작업이었다. 프론트엔드 개발을 하면서 가장 귀찮았던 것이 크로스 브라우징이었는데 디바이스 쪽은 훨씬 고려해야 할 것들이 많았다. 기본적으로 브라우저 대응(iOS -> Safari, Android -> Chrome)및 다양한 해상도와 Notch 등의 디바이스 특성 등을 고려하면서도 전반적으로 데스크톱이 아닌 디바이스이기 때문에 고려해야 할 사항들(보안상 이슈로 인한 동영상 플레이 제한 등)까지 ..