Don’t worry about failures

해당 글은 다른 아티클을 보면서, 편향된 개인적인 생각일 수 있다. 이전 사이드프로젝트를 리팩토링하는 새로운 나만의 프로젝트를 하면서 고민되는 사항이 생겼다. 내가 평소 즐겨쓰던 Styled-component를 현재의 프런트엔드 개발 흐름과 잘어울리까? 에대한 고민이다. 일단, 내가 왜 Styled-component를 즐겨썼을까? 개발자 경험이 가장 크다고 생각했다. 위의 코드를 봤을 때 개인적으로는 div로 표현하기보다는 Container으로 표현하는게 내 눈에는 더 파악하가기가 쉽다고 생각했다. 이 외에도 다른 장점들을 살펴보면, 1. 지역 스코프 스타일드 컴포넌트의 동작 방식을 보면, styled.div에 대한 고유 ID와 style을 적용한 css를 기반으로 해시를 생성하고 생성된 값은 clas..

리액트 팀은 사용자의 경험을 증진시키기 위해 많은 연구를 한다. 이전 글에서 살펴보았던 동시성 모드, 서버 컴포넌트 등을 볼 수 있다. 해당 글에서는 리액트 서버 컴포넌트에 대해 알아볼 예정이다.  리액트 서버 컴포넌트를 살펴보기에 앞서 간단하게 렌더링에 대한 간단한 히스토리를 살펴보자.흐름에 따라 가다보면 리액트 서버 컴포넌트가 나오게 된 배경을 알게되고 이해하는 데에 도움이 되어 먼저 살펴보려한 것이다. 1세대 웹1세대 웹에서는 정말 정적인 웹페이지만 구현이 되었었다. 자바스크립트 없이 서버에서 HTML을 응답하여 브라우저는 그대로 뿌려주기만 한 시대였다. 이 때문에 사용자간의 상호작용이 별도로 존재하지 않았다.  진정한 서버사이드 렌더링이다.  2세대 웹자바스크립트가 등장하면서 웹은 더욱 발전했다...

전역 상태관리를 위해 많은 도구들이 사용된다. recoil, redux, mobx, context 등.. 전역 상태관리에 대해 간단히 알아보고 도구들에 대해 알아보자. 리액트의 경우 컴포넌트를 대부분 작은 단위로 나누어 구조를 구성한다. 부모의 자식, 자식의 자식... 과 같은 구조를 가지게 되고, 상태값은 단방향으로 부모에서 자식에게만 값을 전달이 가능하다. 여기서 자식은 상태를 받기 위해 props를 통해 전달받게 된다. 간단한 구조에 있어 props를 통해 전달받는 것은 문제가 되지 않을 것이다. 반면, 복잡하고 자식의 깊이가 깊다라고하면 props를 자식의 자식의 자식의 자식까지 계속 전달해줘야한다. 이러한 것을 props drilling라고 한다. props를 통해 받는 상태의 단점은 뭘까? 가..

정의 React 애플리케이션에서 SSR을 통해 HTML을 가져와서 React컴포넌트로 변환하고, 클라이언트 측에서 상호작용이 가능한 앱으로 만드는 과정을 말한다. 조금 더 풀어서 생각해보면, SSR은 서버에서 HTML을 생성해서 client에게 전달한다. 이 HTML은 JS가 없는 건조(dry)한 상태이다. 이러한 건조한 상태에서 Hydrate(수화)의 단어 의미 대로 JS를 통해 각 이벤트들을 연결해줌으로써 촉촉한 상태를 만들어 준다는 의미이다. 그럼 만약에 React 애플리케이션에서 SSR을 통해 렌더링을 진행하고자 했지만 Hydrate를 하지 않으면 어떻게 될까? 서버에서 만든 HTML을 무시하고 리액트가 새롭게 만든다. 즉, 서버측에서 생성된 HTML이 아닌 Javascript를 통해 UI를 생성..

React Strict Mode는 애플리케이션 내에서 개발 시 발견된 잠재적인 문제를 감지하고 경고를 출력하는 도구이다. *StrictMode는 development 환경에서만 동작한다. StrictMode가 제공해주는 기능에 대해 확인해보자. 1. 버그를 잡기위해 렌더링을 두번한다. 리액트의 컴포넌트는 순수함수이어야한다. 순수함수가 아닐 경우에는 예측 불가한 상황이나 오류가 생겨날 우려가 있기 때문에 순수함수를 지켜줘야한다. 이를 위해 StrictMode에서는 두번의 렌더링을 통해서 동일한 값이 나오는지 비교하고 그렇지 않으면 경고를 해준다. 이에 대한 예제를 봐보자. 해당 예제는 공식문서에서 가져온 것이다. //App.js import { useState } from 'react'; import St..

Issue Infinity scroll을 구현하면서, 해당 row에 체크하는 기능을 추가. 리스트의 양이 적을 때는 문제 없이 빠르게 체크 영역이 표시가 되었다. But, 리스트의 양이 많아지면서 문제가 생겼다. 2000줄 정도 스크롤을 내리고 선택을 했을 떄 선택 영역의 반응이 매우 느린 이슈가 생겨버렸다. 원인 파악. 1. 클릭한 리스트에 대해 push, slice 같은 함수에서의 시간 복잡도 문제? 2. 렌더링 문제? 원인 1. console.time을 찍어 보았을 때 현 문제되는 이슈의 원인이 되지 않음. ( 물론 slice 부분에서 O(n)에 따라 선택한 리스트가 많아졌을 때 이슈가 존재할 수 있음. 이 부분은 별도록 처리 ) 원인 2. console.log를 찍어 보았을 때, 클릭한 row에 ..

Element Rendering react 앱의 가장 작은 단위 브라우저 DOM 엘리먼트와 달리 react 엘리먼트는 일반 객체. 루트 DOM 노드를 기준으로 react dom이 모든 엘리먼트를 관리. react DOM은 해당 엘리먼트와 그 자식 엘리먼트를 이전의 엘리먼트와 비교하고 DOM을 원하는 상태로 만드는데 필요한 경우에만 DOM을 업데이트한다. Components and Props 리액트에서 컴포넌트는 UI를 기반으로해서 하나 하나의 조각과 같다. 이러한 조각의 형태로써 관리를 하기 때문에 재사용, 확장성과 특정 UI 조각을 집중에서 살펴볼 수 있습니다. angular를 사용하다보니 angular와 비교하여 생각해보자. angular는 component의 개념이 하나의 UI 조각이라는 개념보다는..

About JSX 개념 HTML, 문자열이 아닌, JavaScript Extention 자바스크립트의 확장 문법이다. 즉, 리액트에서는 Javascript를 통해 HTML을 표현하며 view를 구성할 수 있게 도와주는 자바스크립트의 문법 채택하여 리액트의 개발에 큰 도움을 주고 있다. JSX의 표현 JSX는 자바스크립트로 읽어드리지만, 코드상 보이는 형태는 HTML 더 가깝다. 이 때문에 view를 표현하는 데에 있어 더 자유롭다. HTML과 같은 형태의 코드를 변수에 담고 함수에 return값으로 반환하며, view의 렌더링을 구성한다. 이러한 구성과 virtual DOM 때문에 리액트는 더 view를 위한 javascript 라이브러리, 사용자 인터페이스를 만들기 위한 javascript 라이브러리라..