<div id="readability-page-1" class="page"><div><p>다른 프로젝트를 시작중이다.<br>
새로운 영역의 추가가 용이해지도록 리팩토링을 진행하고있다. </p>
<ul>
<li>부모레이어를 하나 더 둠</li>
<li>애매한 네이밍의 함수를 제거</li>
<li>복잡도를 높이는 혼합된 mixin 들을 하나로 합침</li>
</ul>
<h2 id="변동유무">변동유무</h2>
<p>개발할 때 항상 고민이 되는 부분이 있었다.</p>
<p>대표적으로 페이징이 있다.<br>
다음/이전페이지의 동작을 구현하고자할 때,</p>
<ul>
<li>스토어에 하나의 액션을 두고, 컴포넌트에서 페이지세팅을 바꿔가면서 돌려쓴다.</li>
<li>스토어에 각각의 액션을 만들고, 페이지세팅은 액션내에서 처리하고 컴포넌트에서는 호출만한다.</li>
</ul>
<p>두가지의 방법이 있을 수 있다.<br>
만약 페이징정보까지 스토어내에서 관리한다면, 전자의방법은 굳이 컴포넌트에서 단순 페이지세팅을 바꾸기위한 액션을 별도로 dispatch를 해야한다는 번거로움이 있다.</p>
<p>굳이 컴포넌트를 거치지않고 같은 스토어내에서 페이징세팅도 처리하는게 더 깔끔할 것 이라는 생각에 후자가 더 낫다는 생각을 했었다.</p>
<p>그러나 결국 모든것이 요구사항에 따라 결정되는부분이었다.<br>
<strong>페이징방식이 커서방식</strong>(인피니티 스크롤도 포함)이라면 후자로해도 무방하다.<br>
<strong>페이징방식이 번호입력방식</strong>이라면 전자로한다.</p>
<p>사실 그리고 페이징정보도 꼭 store에 가지고있을 필요는 없다.<br>
다른 컴포넌트에서 사용하지 않는다면 컴포넌트의 state로 가지고 있어도 된다.</p>
<p>그러나 Store는 일단 만들고 시작하는게 나중에 확장성측면에서도 좋기때문에 대부분 만들었고, API를 통해 paging정보를 받아오고있다면, 현재구조가 모든 API 호출은 store의 action을 통해서 이루어지기때문에, store에 저장하는게 더 낫다고본다.</p>
<h2 id="언제-어디서-store">언제, 어디서 Store?</h2>
<ul>
<li>부모컴포넌트부터 데이터를 필요로하는 컴포넌트간의 depth가 깊을경우</li>
<li>형제컴포넌트간 공유되는 데이터</li>
</ul>
<p>기존에는 2가지 중 한가지라도 부합할때 store에 데이터를 저장하곤했다.<br>
즉 데이터의 사용범위를 기준으로 store를 나눴엇다.</p>
<p>그러나, 데이터의 사용범위를 기준으로 store에 저장유무를 정했을때 변수가 너무많았다.</p>
<p>첫번째의 경우 depth가 깊다는 기준이 너무 애매모호했다.<br>
top-down 방식으로 컴포넌트를 나누다보면 depth가 깊어지는 경우가 잦아 구분이 쉽지않다.</p>
<p>두번째의 경우에도, 기획에 어떻게 달라질지모르는 상황에서 섣불리 정하기가 쉽지않았다.<br>
예를들어 컴포넌트간의 통신이 전혀 없을 것 같았던 데이터가, 추후 기능개선에의해 구조를 모두 뜯어고쳐야하는 케이스들이 발생했다.</p>
<p>나만의 기준을 정해보았다.</p>
<blockquote>
<ul>
<li>페이지단위로 스토어를 생성한다.</li>
<li>페이지를 사용자와의 인터렉션을 기준으로 영역을 나누고, 각 영역들의 데이터는 store에 저장을 지향한다.</li>
<li>나눠진 영역이 갖고있는 하위 컴포넌트들은 depth가 몇개든 무조건 prop 으로 내린다.</li>
</ul>
</blockquote></div></div>

ginameee.log

Jangchun Lee

다른 프로젝트를 시작중이다.
새로운 영역의 추가가 용이해지도록 리팩토링을 진행하고있다. 
부모레이어를 하나 더 둠
애매한 네이밍의 함수를 제거
복잡도를 높이는 혼합된 mixin 들을 하나로 합침
변동유무
개발할 때 항상 고민이 되는 부분이 있었다.
대표적으로 페이징이 있다.
다음/이전페이지의 동작을 구현하고자할 때,
스토어에 하나의 액션을 두고, 컴포넌트에서 페이지세팅을 바꿔가면서 돌려쓴다.
스토어에 각각의 액션을 만들고, 페이지세팅은 액션내에서 처리하고 컴포넌트에서는 호출만한다.
두가지의 방법이 있을 수 있다.
만약 페이징정보까지 스토어내에서 관리한다면, 전자의방법은 굳이 컴포넌트에서 단순 페이지세팅을 바꾸기위한 액션을 별도로 dispatch를 해야한다는 번거로움이 있다.
굳이 컴포넌트를 거치지않고 같은 스토어내에서 페이징세팅도 처리하는게 더 깔끔할 것 이라는 생각에 후자가 더 낫다는 생각을 했었다.
그러나 결국 모든것이 요구사항에 따라 결정되는부분이었다.
페이징방식이 커서방식(인피니티 스크롤도 포함)이라면 후자로해도 무방하다.
페이징방식이 번호입력방식이라면 전자로한다.
사실 그리고 페이징정보도 꼭 store에 가지고있을 필요는 없다.
다른 컴포넌트에서 사용하지 않는다면 컴포넌트의 state로 가지고 있어도 된다.
그러나 Store는 일단 만들고 시작하는게 나중에 확장성측면에서도 좋기때문에 대부분 만들었고, API를 통해 paging정보를 받아오고있다면, 현재구조가 모든 API 호출은 store의 action을 통해서 이루어지기때문에, store에 저장하는게 더 낫다고본다.
언제, 어디서 Store?
부모컴포넌트부터 데이터를 필요로하는 컴포넌트간의 depth가 깊을경우
형제컴포넌트간 공유되는 데이터
기존에는 2가지 중 한가지라도 부합할때 store에 데이터를 저장하곤했다.
즉 데이터의 사용범위를 기준으로 store를 나눴엇다.
그러나, 데이터의 사용범위를 기준으로 store에 저장유무를 정했을때 변수가 너무많았다.
첫번째의 경우 depth가 깊다는 기준이 너무 애매모호했다.
top-down 방식으로 컴포넌트를 나누다보면 depth가 깊어지는 경우가 잦아 구분이 쉽지않다.
두번째의 경우에도, 기획에 어떻게 달라질지모르는 상황에서 섣불리 정하기가 쉽지않았다.
예를들어 컴포넌트간의 통신이 전혀 없을 것 같았던 데이터가, 추후 기능개선에의해 구조를 모두 뜯어고쳐야하는 케이스들이 발생했다.
나만의 기준을 정해보았다.
페이지단위로 스토어를 생성한다.
페이지를 사용자와의 인터렉션을 기준으로 영역을 나누고, 각 영역들의 데이터는 store에 저장을 지향한다.
나눠진 영역이 갖고있는 하위 컴포넌트들은 depth가 몇개든 무조건 prop 으로 내린다.

2021.10.06

댓글