싱글 페이지 어플리케이션
실시간으로 서버와 데이터를 주고받으면서 현재 보고있는 페이지를 앱처럼 사용하는걸 이렇게 표현하더라
왜 굳이 이 글을 쓰냐면 코드를 어느정도 완성하고나니까 코드짜는 방법에 대해서 어떤게 좋고 나쁜지를 몸소 체험했고
웹 프론트를 제작함에 있어 사전에 지정된 api나 상세한 컴포넌트 작동 diagram이 필요하단 생각이 들었다.
무조건 diagram을 그리라는게 아니라 머릿속에 위 사진 diagram과 유사한 흐름이 들어 있어야한다는것.
난 처음에 이러한 모식도를 전혀 생각하지않고
의식의 흐름대로 a기능을 만들고싶다.a에 관련된 코드를 짜자 라고
그리드 알고리즘마냥 지금 최선의 수만 생각을 해서 코드를 짯는대 이게 좋을때도 있지만 되돌아서 생각해보면 꼭 그렇지만은 않다.
이 글을 쓰게 된 이유
state를 전송받고 컴포넌트간 데이터를 어떻게 주고받을지를 생각하지 않고 짠 코드의 사진인대,
이러한 코드가 짜인대는 내가 서버에서 받아온것들을 어떻게 처리 할지 생각 조차 않아서 그렇게 짠것이다.
그 결과가 이것인대, 저런 코드를 실행시키면 re-rendering때문에 totalpage는 어디에도 존재하지 못한다.
그리고 저런 코드를 짜기 까지에도 많은 시간이 걸렸었다. 지금은 아니지만,
문제
만약 처음부터 페이지와 기능에 대한 기획을 하고 api 결과값에 따른 변수 이동방식에 대하여 미리 생각해두고 난 다음 페이지를 짯더라면 저런 실패값이 존재하질 않았을것이다.
심지어 중간중간에 API결과값을 계속해서 바꾸어 주었다. 그래서 더 더욱 머리가 혼란 스러운 상황에서 코드를 짯다.
_
해결법
그래서 코드 플로우와 react 라이프 사이클을 생각해보고, 어떤식으로 값을 전달할지를 먼저 생각해 본 결과 적절한 api 응답값을 생각 해 내었고,
그에 따라 함수의 구조또한 이전과는 많이 달라졌다.
setState에 내가 만든 객체 type을 통째로 넘겨주어 재 렌더링 시켜주는게 정답이라 생각했고,
이게 원하는 대로 작동한 방식
잘 작동한다.
결론:
이번기회에 며칠동안 삽질하면서 코드의 플로우,여러가지 렌더링 방식 (getInitialProps, serverSideProps등.. )에 대해 알아보았고
기획을 먼저하고 api를 먼저짜고 그 다음 front 페이지를 작성하는것이 좋다고 느꼈다.
코드를 치기에 앞서 내가 하려는 것을 명확하게 지정하고 flow를 구체적으로 생각해 본 뒤에 코드를 짜는게 생산성에도 내 정신건강에도 좋다는걸 알았다. 이번에 짜는 코드는 정말 너무 오래걸렸다.
다음부터 또 이렇게 하긴 싫다.
대략적으로 이런게 머릿속에 들어있어야 편한거같다
추가
이 글을 쓰고나서 또 알아봤는대
좋은 컴포넌트의 조건들을 찾았다.
https://www.youtube.com/watch?v=he6HOA9It7Y&t=432s
-
stateless 가 될수록 좋은 컴포넌트
-
순수함수처럼 작동할것
-
재사용성 유무.
이상 3가지를 알려주는대 여기서 stateless란
https://ibocon.tistory.com/189
이 두가지의 차이 이다.
즉 현재 동작하는 컴포넌트에서 state를 생성할게 아니라
props로 받아와서 함수나 컴포넌트를 작동 시키는것이 가장 좋은 경우라는것.
여기서 알수있는건 props를 받아올때도 한번에서 두번의 과정만 api통신, 상태관리의 store 와 같은 것들을 사전에 거치면된다는것이다.
next js 같은경우 이러한 기능은
첫번째 코드에서 설명 하였듯 페이지가 렌더링 되기 전 props를 가져올수도 있게 할수있는대 아주 좋은 예시라고 할수있다.
렌더링시 front 서버에서 backend에 미리 api요청을 해서 페이지를 어느정도 완성시키고 보낸다.
https://nextjs.org/docs/api-reference/data-fetching/get-initial-props
