104%

작업을 하다가 갑자기 궁금한게 생겨서 레퍼런스를 조사해야겠다는 생각이 들었다. 비슷하게 생기고 비슷한 기능들을 컴포넌트들을 과연 어떻게 네이밍하는것이 좋은 네이밍일까?? 예를들어 서로 비슷하게 생긴 카드들을 카드1, 카드2, 카드3 ... 이렇게 하는게 차선일까?? 아니면 그 카드가 어떻게 생겼는지 형태에 따라 구분하는게 맞을까? 아니면 그 카드가 어디서 쓰이는지를 기준으로 네이밍하는게 맞을까?? 여러 생각들이 들었다. 다른사람들은 어떻게 생각하는지 레퍼런스를 정리해보겠다. 네이밍은 카테고리와 역할에 따라 구분해야한다. Category: mobile, inverse, ui Type: header, hero, title, subtitle, paragraph, button, input, caption Siz..

kentcdodds.com/blog/application-state-management-with-react Application State Management with React How React is all you need to manage your application state kentcdodds.com 요약 리액트에서 상태관리를 위해 항상 Redux를 관습처럼 사용한다. 심지어 컴포넌트 내부에 위치해도 괜찮은 local State까지 Redux를 통해 global하게 관리하는 사람도 많이 봤다. 그렇게 하지말고 차라리 state의 선언 위치를 그 state를 필요로 하는 컴포넌트 그룹의 최상위로 올린다음 props drilling으로 해결해라. 그렇게 하는데 한계가 있을때는 아래와 같이 Conte..

리액트의 렌더링 로직, reconciliation 리액트 컴포넌트가 화면에 렌더링 되는 과정은 다음과 같다. 1. 리액트의 JSX가 React.createElement로 바벨에 의해 트랜스파일링됨. 2. React.createElement함수 호출에 의해 리액트 엘리먼트 트리가 반환됨. 3. React의 reconciliation 알고리즘에 의해 리액트 엘리먼트 트리를 재귀적으로 순회하면서 이전 트리와 현재 트리의 변경사항을 비교한다음 변경된 부분만 실제 DOM에 반영함 (Virtual-DOM) 기존 reconciliation의 약점과 React Fiber의 등장 배경 이런 알고리즘은 애니메이션에 약하다. 1. UI에서는 모든 변경사항을 즉시 반영할 필요가 없다. 2. 데이터에 의한 UI변경보다 애니메이..

React Fiber 리액트의 코어 알고리즘을 재구현한것이다. 리액트의 렌더링은 애니메이션에서 불안한 모습을 보였다. 리액트로 애니메이션을 구현하면 리액트 내부적으로 작동하고 있는 렌더링 알고리즘이 추가로 돌기 때문에 퍼포먼스 이슈가 있었다. 리액트의 Fiber는 이런 문제를 해결해준다. incremental rendering이라고 불리는 이 방식은 하나의 큰 렌더링 작업을 여러개의 작은 렌더링 작업으로 나누어서 실행한다. 이런 방식으로 리액트의 렌더링 알고리즘이 자바스크립트의 메인쓰레드를 전부 차지하지 못하게 막아준다. 원래 기존의 리액트 reconciliation은 재귀적으로 동작하기 때문에 중간에 멈출수가 없었다. 그래서 만약에 이 reconciliation작업이 오래걸린다면 16ms내에 프레임을 ..

서버에서 이런 데이터를 받아왔다고 해보자. 이 데이터를 그냥 써도 괜찮을까? 만약에 위 데이터를 가공하지 않고 그대로 사용하면 어떤 일이 벌어지는지 살펴보자. 만약에 article안에 있는 작성자의 id가 simsimjae인 article을 찾고 싶다면 아래와 같은 코드를 입력해야한다. const id = 'simsimjae' const articles = data.filter(article => article.author._id === id) 이정도는 괜찮다고 생각할지도 모르지만, 만약에 아래처럼 article의 comments 중 id가 simsimjae인 comment를 찾을떈? const id = 'simsimjae' let comments = []; articles.forEach(article ..

FrontEnd Architecture Mobx(3Layer Architecture) React(Dumb Component, Container Component, Page Component) React-Router Component Page Component 라우팅의 단위가 될 페이지 컴포넌트, 단순 랩핑으로써 역할만 한다. Container Component UI컴포넌트(Dumb Component)를 컨트롤 하는 역할 Mobx Store의 데이터를 주입받아 Dumb Component에게 내려주는 역할 Dumb Component의 UI로직이 아닌 라우팅, 데이터 Fetching등의 이벤트 핸들러는 이곳에서 처리함. 라우팅은 컨테이너 컴포넌트에서 처리하도록 한다. Dumb Component === Pres..

{ type: 'div', props: { bgcolor: '#ffa7c4', children: 'hi', }, key: null, ref: null, $$typeof: Symbol.for('react.element'), } react의 element는 이렇게 plain object 형태로 되어 있다. 이중에서 $$typeof는 왜 필요한건지 궁금해서 찾아보았다. Symbol.for $$typeof의 value로 사용된 공유 심볼에 대한 이해가 먼저 필요하다. (링크) 간략하게 얘기하면 react.element라는 string key를 가진 유니크한 글로벌 심볼을 리액트 엘리먼트의 property중 하나로 사용한것이다. React.createElement(type, props, children) Reac..

Mobx에서 observable state를 변경하려면 항상 액션을 통해서 변경하는것을 추천한다. 그래야 Mobx가 state변경 사항을 모아서 한번에 처리해줄 수 있기 때문이다. @action 데코레이터나 action() 함수는 현재 실행중인 함수에만 적용된다. 현재 함수에 의해서 스케쥴된 함수에는 액션이 적용되지 않는다. 이게 무슨말인지 자세히 살펴보자. // state가 항상 action으로만 변경되게끔 설정하는 옵션이다. mobx.configure({ enforceActions: "observed" }) class Store { @observable githubProjects = [] @observable state = "pending" // "pending" / "done" / "error" @..