<div id="readability-page-1" class="page"><div><p>구직활동을 위해 거진 3달만에 개발을 손에 잡는다.<br>
문법도 기억이 안나고 큰일이다.<br>
그동안 일하면서 갖고있던 생각들을 복기하고 정리해본다.</p>
<h2 id="개발전에-데이터구조를-먼저-확인논의하자">개발전에 데이터구조를 먼저 확인/논의하자</h2>
<p>정석대로라면 데이터설계 및 API가 먼저 개발된 상태에서 화면개발이 진행된다.<br>
(실제 현업에선 화면리뉴얼과 같은 케이스를 제외하고는, 신규개발에서 API가 먼저 개발되는 경우는 거의 없다.)</p>
<p>API가 먼저 주어졌을 경우 response의 데이터 구조를 먼저 파악하고, 컴포넌트와 스토어의 구조를 먼저 잡는게 좋다.</p>
<p>API도 동시에 개발이 진행된다면, 데이터구조를 혼자 상상해서 무작정 화면을 만들지 말고 백엔드개발자분들과 사전에 충분한 논의 후에 mock 화면을 진행하도록 하자.</p>
<p>당장은 진행이 더뎌보이고 다가오는 마감날짜에 조바심이 날 수 있어도, 나중에 다 만들고 뜯어고치는것 보다 낫다.</p>
<h2 id="관심사분리">관심사분리</h2>
<p>React 에서 관심사를 분리할 수 있는 크게 3가지 정도 인 것 같다.</p>
<ul>
<li>hook </li>
<li>store</li>
<li>util</li>
</ul>
<h2 id="util">util</h2>
<p>먼저 <code>util</code>은 react 컨텍스트와 관련없는 순수함수일 경우 분리한다.<br>
나의경우 상수값까지 까지 함께 넣거나 아니면 <code>constants</code>라는 별도의 파일을 만들어 분리하기도 한다.</p>
<h2 id="hook">hook</h2>
<p>특정 callback 시점에 수행되는 공통적인 로직을 위해 분리하는 경우도 많지만, 대부분 state와 짝을 이루어 분리하는 경우가 많은 것 같다.</p>
<p>컴포넌트 내부에서 state의 갯수가 많이 늘어난다면, state와 관련 로직들을 분리하여 hook으로 빼내면 좋다.</p>
<blockquote>
<p>그러면 Component 에는 어떤로직과 state가 있는게 좋을까?<br>
가장 좋은건 handler와 UI의 상태값 (clicked, selected 유무) 만을 저장하고 관리하는게 좋아보인다.</p>
</blockquote>
<h2 id="store">store</h2>
<p>여기서 내가 말한 store란, 애플리케이션의 전체 상태관리를 위한 저장소다. 구현하기위해선 다양한 방법들이 있다.</p>
<ul>
<li>Redux</li>
<li>Mobx</li>
<li>recoil / jotai</li>
</ul>
<p>뭘 선택하든지는 지금 주제와는 관련이 없고, store에 로직을 분리하는 기준은 앞서 <code>hook</code> 설명에서 state와 관련된 로직을 묶어 분리한다고 이야기 것과 유사하다.</p>
<ul>
<li>애플리케이션 전체에서 필요로하는 상태값</li>
<li>이 상태를 조작하는 로직들</li>
</ul>
<p>이 2개를 묶어서 store 라는 하나의 묶음으로 관리한다.<br>
상태를 조작하는 로직의 경우 redux를 사용했을땐 action, reducer 가 될 수 있겠고, recoil이나 jotai를 사용한다면 getter와 setter 가 될 수도 있을 것이다.</p>
<p>나의 경우 store생성을 위한 라이브러리가 제공하는 getter setter API를 활용하기보다, 조작을 위한 별도의 hook을 생성하곤 한다.</p>
<p>이유는, hook으로도 별다른 이슈없이 대체가 가능하고, 해당 라이브러리에 익숙하지 않은 동료가 봤을때 hook으로 작성된 코드를 읽는것이 더 편리할 것 이라고 생각하기때문이다.</p></div></div>

ginameee.log

Jangchun Lee

구직활동을 위해 거진 3달만에 개발을 손에 잡는다.
문법도 기억이 안나고 큰일이다.
그동안 일하면서 갖고있던 생각들을 복기하고 정리해본다.
개발전에 데이터구조를 먼저 확인/논의하자
정석대로라면 데이터설계 및 API가 먼저 개발된 상태에서 화면개발이 진행된다.
(실제 현업에선 화면리뉴얼과 같은 케이스를 제외하고는, 신규개발에서 API가 먼저 개발되는 경우는 거의 없다.)
API가 먼저 주어졌을 경우 response의 데이터 구조를 먼저 파악하고, 컴포넌트와 스토어의 구조를 먼저 잡는게 좋다.
API도 동시에 개발이 진행된다면, 데이터구조를 혼자 상상해서 무작정 화면을 만들지 말고 백엔드개발자분들과 사전에 충분한 논의 후에 mock 화면을 진행하도록 하자.
당장은 진행이 더뎌보이고 다가오는 마감날짜에 조바심이 날 수 있어도, 나중에 다 만들고 뜯어고치는것 보다 낫다.
관심사분리
React 에서 관심사를 분리할 수 있는 크게 3가지 정도 인 것 같다.
hook 
store
util
util
먼저 util은 react 컨텍스트와 관련없는 순수함수일 경우 분리한다.
나의경우 상수값까지 까지 함께 넣거나 아니면 constants라는 별도의 파일을 만들어 분리하기도 한다.
hook
특정 callback 시점에 수행되는 공통적인 로직을 위해 분리하는 경우도 많지만, 대부분 state와 짝을 이루어 분리하는 경우가 많은 것 같다.
컴포넌트 내부에서 state의 갯수가 많이 늘어난다면, state와 관련 로직들을 분리하여 hook으로 빼내면 좋다.
그러면 Component 에는 어떤로직과 state가 있는게 좋을까?
가장 좋은건 handler와 UI의 상태값 (clicked, selected 유무) 만을 저장하고 관리하는게 좋아보인다.
store
여기서 내가 말한 store란, 애플리케이션의 전체 상태관리를 위한 저장소다. 구현하기위해선 다양한 방법들이 있다.
Redux
Mobx
recoil / jotai
뭘 선택하든지는 지금 주제와는 관련이 없고, store에 로직을 분리하는 기준은 앞서 hook 설명에서 state와 관련된 로직을 묶어 분리한다고 이야기 것과 유사하다.
애플리케이션 전체에서 필요로하는 상태값
이 상태를 조작하는 로직들
이 2개를 묶어서 store 라는 하나의 묶음으로 관리한다.
상태를 조작하는 로직의 경우 redux를 사용했을땐 action, reducer 가 될 수 있겠고, recoil이나 jotai를 사용한다면 getter와 setter 가 될 수도 있을 것이다.
나의 경우 store생성을 위한 라이브러리가 제공하는 getter setter API를 활용하기보다, 조작을 위한 별도의 hook을 생성하곤 한다.
이유는, hook으로도 별다른 이슈없이 대체가 가능하고, 해당 라이브러리에 익숙하지 않은 동료가 봤을때 hook으로 작성된 코드를 읽는것이 더 편리할 것 이라고 생각하기때문이다.

2024.01.15

댓글