이번에 설계 측면에서 고려해볼 계기가 생겨서 그거 다시 고민하면서 그 생각의 흐름을 일종의 시리즈를 가진 에세이로 쓰고 있음.
글로 쓰자니 빡세긴한데 정리도 되고 보여주기 용으로 또 뉴비들이 보면 나쁘지 않을거 같아서 조금씩 쓰는중.
프론트엔드 설계에 대해서 어떻게 할지 고민하는 애들은 한번 봐보셈.
https://isa-dev.tistory.com/236
https://isa-dev.tistory.com/237
이번에 설계 측면에서 고려해볼 계기가 생겨서 그거 다시 고민하면서 그 생각의 흐름을 일종의 시리즈를 가진 에세이로 쓰고 있음.
글로 쓰자니 빡세긴한데 정리도 되고 보여주기 용으로 또 뉴비들이 보면 나쁘지 않을거 같아서 조금씩 쓰는중.
프론트엔드 설계에 대해서 어떻게 할지 고민하는 애들은 한번 봐보셈.
https://isa-dev.tistory.com/236
https://isa-dev.tistory.com/237
저번에 리액트 뜯어본거는 좀 구렸는데 이건 내용 좋노ㅋㅋ
잘 봤습니당 저도 비슷한 생각을 했어서 금방 읽었네용
해당 댓글은 삭제되었습니다.
index.js에 스토어를 넣는 이유는 이 노드환경에서 실행되든 브라우저환경에서 실행되든 스토어에 데이터 주입을 편하게 하기 위해서임
https://redux.js.org/usage/server-rendering#handling-the-request
App 내부에서 provider해도 구조상 동일한데 ㅇㅅㅇ?
이렇게 하고 앱안에서 이렇게 한다고?
리액트 라우터도 App안에 Routes, Route를 구성하는 건 상관없는데 Router는 index.js쪽으로 빼야함 그래야 서버에서는 스태틱 라우터를 씌우고 브라우저에서는 브라우저 라우터를 씌울 수 있음
https://reactrouter.com/docs/en/v6/guides/ssr
참고
댓글로 태그를 못다네 App의 프롭스로 store를 넘기고 앱내부에서 그 프롭스를 그대로 프로바이더에 던진다는 의미임?
밥 먹고 정리해봄
컨셉을 유지 하려면 초기 preloaded state만 app에서 props받거나 애초에 app 내부에서 해당 로직을 실행되면 되는 문제지 렌더링 구조상 서버에서 만든 store 상태값을 다시 받아서 초기화하는거니까 구조적으로 그냥 해당 코드 위치가 웹앱에 위치하냐 index에 위치하냐 차이임 혹시나 내가 착각한게 있나 다시 살펴봤는데 없음
어차피 ssr을 하든 안하든 둘다 동시에 하든 코드상으로 차이가 없음 데이터 주입 방식 자체가 전역 변수 선언하고 그걸 다시 csr 사이드에서 불러와서 스토어를 초기화 하는 것이기 때문에
즉 ssr이나 csr이나 데이터 주입의 용이성을 위해서 store 관련 코드를 index에서 주입한다고 볼 수 없음. 라우팅 관련은 내가 명확히 답변 불가능하지만 니가 말한 것 처럼 많이함