GraphQL is a query language for APIs and a runtime for performing queries on data that already exists.

GraphQL Korea

제가 알기로는 없는데... 어떤 유즈케이스에서 나온 건가요?

한 컴포넌트에서 탭을 여러개를 두고 있는데, 각 탭에서 동일한 쿼리를 다른 방식으로 불러오고 있습니닷

그냥 변수를 하나 만들어서 랩핑하고 탭 바뀔때마다 초기화 시키는 방식으로 해결했습니다 :slightly_smiling_face: 감사합니다

alias쓰시면 되지 않을까요?? ㅎㅎ

```query something {
  tab1: sameQuery
}```
```query something {
  tab2: sameQuery
}```
```query something {
  tab3: sameQuery
}```
apollo client 내부에서 어떻게 처리되는지 잘 몰라서 ㅋㅋ 될지 모르겠네용

GraphQL 프로젝트는 아니지만 recoil 쓰고있는데 넘나 만족중입니다..

참, recoil도 있었군요? 실무에서도 사용할 만한가요?

저는 쓸만하다고 생각합니다 (저도 만족중) graphql 클라이언트로 리모트 리소스가 관리될테니, 그 외에 상태를 관리할 때 좋고

네네 너무 간단하게 사용할 수 있고, 다른 것들은 hook 넘어오면서 사용하기 애매한 것들 많았는데(이 부분은 제가 경험이 부족해서 그런것 일수도..), state, async, suspense 지원하고 있어요 ㅎㅎ

recoil 이 서스펜스를 지원하다보니 가끔 리모트 리소스를 땡겨와야 하는 케이스를 쓰게 되는데 이때를 주의해야 합니다 ㅋㅋㅋ..

오 그렇군요, 한번 리서치 해봐야겠네요! 두 분 모두 감사합니다 :slightly_smiling_face:

다른 프로젝트에 react-query + recoil 로 하고 있는데 각각 역할을 명확히 해야 할 필요가 있었습니다. rq 자리에 아폴로나 릴레이 또는 뭐든 들어가실테니 ㅎㅎㅎ

+ 간단한 상태머신 필요할때마나 리듀서 작성

그러고보니 로컬 상태 관리에도 좋다고 여러번 귓동냥 해서 들었는데 써먹어보진 못했네요

GraphQL 로 로컬 상태 관리인가요? 아폴로의 `@client` directive 같은?

어음.. 그거 콕집어서 얘기하려던건 아니고용

대부분 상태관리 라는 키워드가 등장하면 그 맥락에서 진실의 원천은 네트워크 내지는 캐시이기 때문에

뭐 pouch db 같은거 쓰면 또 모르겠네요

그렇군요 graphql 쪽도 한번 봐야겠네여!

저희가 내부적으로 Microservice 환경으로 되어있는데요. 이걸 Aggregation하는 GraphQL 서버를 개발하고 배포, 관리하는데 리소스가 부족하다보니, 클라이언트 스키마를 사용했어요 ㅎㅎ

추가적으로는 Relay를 쓰고 싶어서요 ㅎㅎ

커서를 2개 컬럼이라고 말씀하시는건 sort 기준이 두개라는 뜻이겠죠?!

String으로 concat해서 구현할거같아요

저는 내부 공용 컴포넌트 (디자인 시스템 등등)는 SCSS + CSS Modules로 하고 프로덕트는 CSS-in-JS 선호해요

<https://github.com/callstack/linaria>

이런 솔루션을 얼마전에 찾아서 도입해볼까 고민하고 있어요 ㅎㅎ

오 답변 감사합니다! 디자인 시스템은 저도 SCSS가 맞는것 같은데 CSS in JS가 성능적으로 이슈가 없을까요?

넵 ㅎㅎ 애니메이션을 props로 처리하지만 않으시면 충분해요

그렇군요, 그러면 저 linaria 이전에는 styled-components 나 emotion 사용한 프로덕트가 있으신가여?

네 저희 당근마켓 웹뷰는 전부 emotion이에요

당근마켓 - "내근처" 탭이 emotion 기반입니다

웹뷰라 하심은 모바일에서 볼 때인가요?

아 그러면 emotion (CSS in JS) 사용하시면서 SCSS 보다 어떤게 편하다고 느끼셨나요?

모든면에서 좋은거같아요 ㅎㅎ class로 처리안하다보니까 그때그때 동적으로 height를 정해준다던지도 할 수 있게 되구요!

답변 감사드립니다! :slightly_smiling_face:

틈새질문드립니다;; 디자인 시스템에서 scss 사용하는 것은 번들사이즈에 대한 이점이 맞나요??

네네 그것도 그렇고 저희는 한 제품을 만드는데 기술 스택 선택을 각 프론트엔드 개발자가 알아서 하고있거든요 ㅎㅎ 만약에 어떤 개발자분이 emotion을 안쓰는데, 공용 컴포넌트를 쓰게되면 번들사이즈가 커질꺼같아서, 일단 공용 컴포넌트들은 CSS Module로 하고 있어요.

아 감사합니다!!! dx 도 챙기면서 번들사이즈도 작게가져가는 거슨 저 리나리아(?)가 희망일까요

리액트 알못인데, *linaria는 그냥 styled-component랑 무슨 차이가 있는건가요? 겉보기에는 비슷해보여서요 ㅎㅎ*

```@linaria/webpack-loader```
를 이용해서, CSS 파일로 뽑아낼수있습니다 ㅎㅎ

오,, 그러면 css 파일 뽑아내서 다른 프론트엔드 라이브러리(혹은 프레임워크) 에서도 활용이 가능하겠네요…

CSS Class 이름이 뒤죽박죽이라 그건 힘들지 않을까요? ㅎㅎ

아, 그런가요? 그러면 css 뽑아내는 게 어떤 이점이 있는건가요? (정말 알못이라.. :eyes:)

Zero-runtime CSS-in-JS 라고 하는데요

쉽게 생각하면 API 스타일은 Styled-Component 인데 실제 동작은 SCSS 같은 녀석이라고 보시면됩니다.

Linaria는 아예 코드 의존성 분석이랑 추출 실행까지 다 하기 때문에

컴파일타임에 쓸 유틸리티를 JS로 작성할수 있다는게 장점이고

런타임이 없다는게 장점이자 단점이죠

조금 치명적이라고 생각하는 단점은

저거 만든 Callstack 이라는 팀이 RN만 쓰는 팀이라

&gt; Linaria는 아예 코드 의존성 분석이랑 추출 실행까지 다 하기 때문에
그리고 이 부분 복잡성 문제때문에 좀 프로덕션에서 쓰기 어렵다는 부분이 있었는ㄷ데 v2 나오고서는 테스트를 못해봤네요

<https://compiledcssinjs.com/> 이런애들은 순수 정적 분석

저는 개인적으로 작은 런타임이 존재하는 + Atomic CSS 를 지원하는 라이브러리를 선호해요

최근 가장 즐겁게 쓰고 있는건 이친구입니다. <https://stitches.dev/>

&gt; CSS in JS가 성능적으로 이슈가 없을까요?
CSS 삽입할 때 JS 런타임 비용은 생각보다 사소할 수 있습니다 (사이트마다 케바케지만)  Emotion/SC 는 Stylis 라는 경량 CSS 파서에 의존하는데 이친구가 굉장히 빨라서 런타임 벤치마크 돌려도 CSS Module 쓰는거랑 별 차이가 안나요. 오히려 output 을 사이트 워터폴에 어떤식으로 통합하는지가 더 중요합니다

왜 런타임이 있는걸 선호하는지를 여기다가 적어놨어요 <https://blog.cometkim.kr/posts/css-optimization-in-jamstack/>

공유하는 라이브러리를 만들때 제일 권장드리고 싶은 방식은, 최대한 구성이 유연한 런타임 라이브러리 선택해 미리 합의를 갖춰놓는 겁니다. (ex. emotion)

가령 emotion 처럼 리액트에 깊게 통합될 수 있는 라이브러리들은 뭘 할 수 있냐면

컴포넌트 렌더링할 때 스타일 통합되는게 대표적으로 두가지 방식이 있는데요.
• CSS Extraction
• Interleaving style tag

CSS Module 이나 SCSS 같이 정적인 친구들은 선택지가 없어요 무조건 사전 extraction 입니다.

그리고 글에 기술한거처럼 CSS Extraction을 했을 때  Zero runtime 라이브러리들은 리액트 렌더링 맥락에 따른 추가적인 최적화를 할 수가 없습니다.

더군다나 여느 OOCSS 들이 그렇듯이 중복이 많아서 코드베이스에 따라 CSS 사이즈가 가파르게 커져요

페이스북은 이걸 Atomic CSS 로 해결했다고 발표했었죠

물론 Atomic output 이면서 Zero runtime 접근방식 취하는 라이브러리도 상당히 많고요

다만 접근방식에 따라서 얻고 잃는것들이 많으니 검토를 꼼꼼히 해보시는걸 추천드리고

본심: 진짜 왠만하면 그냥 회사에선 이모션 쓰세요

(물론 이것도 타입스크립트 이슈 생각하면 갈아버리고 싶지만...)

&gt; CSS Module 이나 SCSS 같이 정적인 친구들은 선택지가 없어요 무조건 사전 extraction 입니다.
아 Atlassian 의 compiled-css-in-js 라이브러리는 또 독특해서 예외입니다

엌… 생태계가 참 복잡하네요… ㅋㅋㅋ

이쪽(CSS-in-JS) 맥락 상당히 넓죠 ㅋㅋ

필드에선 선택지가 많이 좁혀지긴 합니다

• 리액트만 씀, 런타임 필요 -&gt; Emotion or Styled-components
• 런타임 없어야 함, 유틸리티 first 선호 -&gt; Tailwind
• 컴포넌트 우선, 철저히 theme 기반으로 스타일링 함 -&gt; 자체 디자인 시스템 라이브러리

여기서 런타임이랑 디자인 시스템이랑 맥락이 애매하게 걸쳐서

따로 보면 알아야할(?) 내용이 더 많긴 합니다

또 디자인시스템 라이브러리 만드는데서 런타임도 만드는 경우도 많고요

어떤 디자인 시스템이 어떤 런타임에 의존하는지도 보셔야합니다

가령
• Material-UI: JSS (차세대에 뭐쓸지 반년째 싸우는중)
• Uber Base: 과거 Emotion -&gt; 현재 Styletron
• Antd: Less 기반 스타일 시트 유틸리티
등등...

아예 스타일 없는 headless component로 접근성 중시한 빌딩블럭만 만드는 추세도 있는 것 같고요

ㅋㅋ안그래도 <https://github.com/mui-org/material-ui/issues/21453#issuecomment-751872986> 요거 유심히 보고 있었는데,, 이모션으로 하는 것 같더라고요??

아 이건 다른 이슈를 링크했네요

<https://github.com/mui-org/material-ui/issues/22342>

너무 오랫동안 끝나지 않는 전쟁을 하고 있어서

이쪽진영은 진짜 토론을 빡시게 하는 느낌이에요

중간에 우리 styled-components 간다! 했다가 와장창이라서

JSS 잘쓰고 있는데 왜버리냐... emotion 이 낫지 않냐... 아님 또 뭐가 낫지 않냐... 사실 성능이 어떻다.... 벤치마크 잘못짠거다 등등

느낌상으로는 추세가  sc 를 꺼리고 웬만하면 이모션을 쓰는 느낌,,

emotion 이 훨씬 잘 만든건 맞습니다. (예전엔 가파르게 발전했는데 요즘은 되려 느려진거 같긴함)

sc도 내부적으로는 emotion을 써요

정확히는 emotion 의 코어모듈 몇개를 의존하고있죠

아마 stylis 포크도 둘이 공유할걸요

최적화는 sc가 더 빨리 달성했고 emotion 11은 진통을 겪고 있죠

이모션 마이그레이션 너무 고통스러움

둘이 서로 영향을 준부분이 너무 많아서 emotion 버전 9 &amp; sc 버전 4 부터는 둘이 구분하는게 별 의미가 없어졌죠

저는 그냥 MUI 를 헤비하게 쓰는 입장에서 MUI컴포넌트 딥하게 스타일 오버라이드할땐 makeStyles(JSS) 쓰구 간단간단한건 sc 쓰고 요러고 있었어요

사실 JSS도 확장성이나 이런저런 측면에서 상당히 괜찮은 물건이였는데

JSS 만든이가 MUI 멤버여서 그런지 초반에 씨게 밀더라구요

MUI가 거의 짊어지다시피 했으니 생태계 자원을 빌린다기 보단 생태계가 유지보수를 떠안은 듯한 그림이 되서

그러게요 거의 여기 말고는 쓰이는데가..??

아 근데 emotion DX도 상당히 구리죠

CSS in JS API의 미래를 엿보고 싶으시면

작은 프로젝트라도 Stitches 를 써보시죠

최신 생태계 연구들을 반영하면서도 DX를 철저히 고민한 라이브러리죠

아니면 원래질문인
&gt;  SCSS를 선호하시나요 아니면 CSS in JS를 선호하시나요?
에서 중간쯤 되는 녀석도 있는데요

(이름이 기억 안나서 끙끙대는중

대충 타입스크립트로 쓸 수 있는 CSS Module 같은 거 라 생각하시면 됩니다.

네 맞아요 ㅎㅎ Redis를 활용하면, graphql-subscription에서 (요거 쓰시는게 맞나요?) Event emit이 일어날때마다 Redis PubSub으로 쏴주고요. Redis PubSub에서 다른 노드들의 graphql-subscription 구현에 해당 이벤트를 전달해준다고 생각하시면 돼요!

<@UN0GLRW14> 감사합니다!! 제가 이해한게 맞다면 redis를 사용하지 않는다면 여러 개의 노드 인스턴스들이 각각 PubSub 객체를 가지고 있게 되는 건가요??
그리고 redis 내부적으로 다른 노드들에게 모두 이벤트를 전달할 수 있도록 구현이 되어 있는 건가요??
아 그리고 저는 graphql-redis-subscriptions 사용하고 있습니다!

감사합니다!! 정말 많은 도움이 되었습니다!

yarn은 프로젝트마다 따로 설정하실수있어요 ㅎㅎ

글로벌에는 yarn 1을 기본으로 설치하시면 되고

yarn 2 쓰고싶은 프로젝트에서

```$ yarn set version berry
$ yarn set version latest```

오... yarn은 프로젝트마다 버전 관리를 따로할 수 있군요???
yarn으로 넘어가야겠네용...

Yarn 2 쓰려고 했지만 초기 설정부터 eslint에서 막혀서 yarn 1을 써야겠습니다…

Yarn 2로의 전환은 프로젝트에 바이너리를 벤더링하는걸로 시작돼요

Yarn 버전관리는 제가 항상 추천드리는 asdf로 같이 할 수 있긴 하지만 별 의미가 없습니다.

{...props} 위쪽의 4개 데이터 때문에 완전히 분리를 할 수가 없는데요, 어떻게 하면 좋을까요? 지금은 Context 를 써야 하나 고민중입니다

저 같은 경우는 저 4개 props를 리턴하는 커스텀 훅을 만들어서 부모 컴포넌트에서 호출한 뒤에 커스텀 훅이 리턴한 props를 자식 컴포넌트에게 주입시켜서 부모 컴포넌트에서 자식컴포넌트의 스테이트를 사용할 수 있게 합니당.

혹시 자식 컴포넌트에 주입시킬때 어떻게 전달하시나요??

음... 제가 질문을 좀 잘못이해한 것 같아용.
궁금한게 있는데 예시만 보면 props 위쪽의 4개 데이터 때문이 아니고 props때문에 컴포넌트를 리턴하는 인라인 함수가 만들어진 거 아닌가용??

네네 죄송해요 저도 이걸 어떻게 질문해야 좋을지 좀 난감해서
억지로 분리를 하면 아래처럼 되는데용(selectedStartDate... 외 3개 데이터는 원래 부모로 부터 와야하는데 그냥 구색맞춰서 예시로 넣은겁니다!)

그럼 이게 결국 제가 사용하는 라이브러리의 prop으로 들어가게 됩니다
말씀하신 props는 저 라이브러리에서 콜백형태로 제공되는 값들이에요!

아무래도 샌드박스로 재현을 해서 올리는게 나았겠네요 ㅜ.ㅜ 혼란을 드려 죄송합니다

꼭 ConfirmPreStock을 가지고있는 컴포넌트에서 selectedStartDate 등의 state와 이벤트핸들러를 가지고 있어야한다면, Toolbar가 넘겨주는 props를 args로 받아서 args와 selectedStartDate등을 MTableToolbarFilter에 주입해서 리턴하는 함수를 useCallback으로 감싸면 매 렌더링마다 새로 렌더링되는 일은 막을 수 있을 것 같아용.

물런 저도 뇌내 망상이라 ㅎㅎ...

저도 처음에 메모이제이션을 해볼까 했는데 결국 디펜던시가 변경되면 함수가 새로 실행되는 건 같아서 unmount되고 새로운 컴포넌트가 생기더군요 ㅜ.ㅜ

아아... 리렌더링이 아닌 언마운트/마운트가 되는군용....

누군가 나타나셔서 해결해주시면 좋겠네요... 저도 궁금해서...

넴 퇴근후에 샘플코드를 한번 짜보겠습니다..!

컴포넌트를 넘기지마시고 render prop 으로 넘기세요

아니면 차라리 element 를 넘기시는게 낫습니다

일단 재현은 이렇게 해봤는데요 <https://codesandbox.io/s/vibrant-carson-7q2sl?file=/src/App.js>

혜성님 말씀대로 한번 시도해볼게요

음.. 일단 SomeComponent.js 부분의 인터페이스가 라이브러리쪽 코드 부분에 해당해서 저기를 바꿀 순 없는 상태인데 어떻게 엘리먼트나 렌더 프롭으로 넘겨야할지 모르겠네용,,

어떤 라이브러리가 component 를 prop으로 받나요

이건 뭐 SomeComponent 를 memo 하는거 말고는 방법이 없는데여

애초에 추상화가 상당히 잘못된거같아요. 컴포넌트를 믹스인 해서 새 컴포넌트를 만든다고 하더라도 모듈 스코프에서 해야지 렌더 스코프에서는 정적이여야해요. 이거의 예외가 as props 라는 패턴인데 이거 썩 좋지 않습니다

메모는 React.memo 쓰시면 되고, 두번째 인자로 comparator 넘길 수 있습니다. 그걸로 componentProp 변경은 무시하게 하시면 됩니다. 물론 이러면 동적으로 컴포넌트를 변경하실 수 없고요

<https://github.com/mbrn/material-table> MUI 에서 complementary project 로 추천해서 도입했었던 lib인데 쓸수록 한계에 부딪히네요 그래서 새로 추가하는 코드는 react-table 로 하고 있긴한데 이미 많은 부분을 차지하고 있는,,

네네 흐 그러면 저같은 경우는 prop에 따라서 컴포넌트 변경이 되어야 하는 케이스(sandbox 에서의 input 부분)이니 메모는 사용을 못하겠고.. react-table 을 사용하거나 다른 방법으로 억지스럽게 데이터를 넘기는 수밖에 없겠군요 ㅜ

컴포넌트는 모듈스코프에서 정의하시고요

"prop 에 따라서 컴포넌트 변경" 이 부분을 제거해보세요

일반적으로는 제거할 수 있습니다

정 안되면 컨텍스트를 하나 만드시고요

근데 step in 때문에 Material table 필터를 저렇게 커스터마이징 하는것도 꽤 불편할 일인 것 같네요 일반적인 테이블 컴포넌트 주변 역할을 한참 벗어나는거같은데요

필터 컴포넌트가 table 의 child가 아니라 sibling 이라고 생각하는게 더 적합할 것 같습니다. 부모는 상태컨테이너일테고 table은 representation에 충실하게 만드셔야 할듯

"필터 컴포넌트만" 바꾸고 싶으시다면 기능을 Material Table에서 독립하시고

그게 아니라면 필터 컴포넌트 자체가 더 stateful 해져야 하는 케이스 같습니다.

pre...confirm 페이즈에만 filter 컴포넌트를 attach 한다 X -&gt; filter 컴포넌트가 pre...confirm 페이즈에 반응한다 O

네 라이브러리 자체가 기능을 우겨넣다보니 bloated 된 느낌이 없잖아 있어요

맞아요 아예 필터를 떼놓고 구현하는 옵션도 있었는데 잊고 있었네요

근데 누군가 reactiflux 에 신기한 답변을 달아놔서 구경중입니다;; <https://codesandbox.io/s/elated-archimedes-bg6e5?file=/src/App.js>

rest props 포워딩 해줘야 넘어가지 않나요

올려주신건 SomeComponent 가 prop 을 포워딩을 안하고 있고요

음 그러게요,, 저도 타이핑해보고 어 되네 해서 봤는데 inputValue가 계속 undefined

```export default ({ componentProp, ...props }) =&gt; {

  return (
    &lt;div&gt;
      &lt;Component data={data} {...props} /&gt;
    &lt;/div&gt;
  );
};```

다만 이건 Material Table 이 이렇게 해줘야한다는 소리라 옵션은 아니고요

그냥 options.filtering 만 토글해줘도 되는거 아닌가욤

아?? 잘 이해를 못했어요 material-table option에 filtering 말씀이신가요?

그냥 피쳐 자체를 관리하는걸로 기억하는데

제가 쓸때는 컴포넌트 오버라이딩 관련해서 사용할 때 큰 문제 없었거든요

아 근데 그러고보니...제가 저 기능을 지금 왜 필터에 넣고있었는지 모르겠네요 ?!

네 저거 아니면 다른 options 에서 제공하는 플래그들이요

필터랑 상관없이 쿼리할때 필요한 것들이었는데

제가 쓰던 기억엔 저런 코드가 나올일이 없었기에...

이거 한번 다시 제대로 생각을 해보고 돌아오겠습니다 ;; 감사합니다!!

엇 이거 잡담에 올린다는게 질문에 올렸었네요;;

저도 이거 궁금하네요 ㅋㅋ 이전에는 _app.ts에서 getInitialProps로 getDataFromTree 때리고 cache를 말아줬었는데... getServerSideProps의 approach를 보면 요 방법이 좋은 방법은 아닌거같구요.

앗 지혁님 아실줄 알았는데 ㅋㅋㅋ

Vue 하다가 Nextjs로 넘어왔는데 아직 잘 몰라서 넘 슬픕니다 ㅋㅋㅋ

`If you're using Next.js 9.3 or newer, we recommend that you use getStaticProps or getServerSideProps instead of getInitialProps.`

곶통받는 중입니다....ㅋㅋㅋ

해당 의문을 들게한 코드 작성자입니다. ㅎㅎ....
api 호출을 두번 때린다기 보단, 아폴로 캐시 스토어에 하이드레이션된 데이터를 사용하기위한 코드가 컴포넌트단에 한번 더 들어갑니당.
네트워크 콜 자체는 한번해용!

`두번 동일한 쿼리를 호출` -&gt; `두번 동일한 쿼리를 작성`  으로 정정합니다 (_ _)

또이잉... 두번 작성해야되나요?? Apollo는 getDataFromTree 하면 안되나요? 저는 Relay 쓰다보니 두번 작성하는 문제는 없던거같네요 ㅠ

예제코드입니당.

현재 위 코드와 같은 방식으로 `getServerSideProps` 에서 네트워크 콜 후에  해당 데이터를 아폴로 캐시에 하이드레이션 시키고 컴포넌트에서 같은 쿼리를 호출해서 캐시스토어의 데이터를 사용하는 식이에용~

`getServerSideProps` api 자체가 서버사이드에서만 실행되다보니 CSR에서 네트워크콜을 위한 쿼리도 필요하긴 한 상황입니다 :slightly_smiling_face:

• `getInitialProps`: 맨 처음 SSR 당시에만 실행됨
• `getServerSideProps`: path 이동시에 자동으로 Next.js에서 서버에 요청을 날리고 `getServerSideProps`의 응답을 페이지 컴포넌트의 Props로 자동으로 넣어줌
요 차이 맞죠?? 그러면 `getServerSideProps`를 썼을때 CSR에서 데이터 페칭을 하는 패턴이 맞나 싶어서요 ㅋㅋ

&gt; 또이잉... 두번 작성해야되나요?? Apollo는 getDataFromTree 하면 안되나요?
아뇨 ㄱ냥 문서대로 쓰면 돼용

<https://www.apollographql.com/docs/react/performance/server-side-rendering/#executing-queries-with-getdatafromtree>

getServerSideProps 에 의존하실 필요가 없을텐데

preloading/prefetching 때문에 그러시는거면 다른 걸로 해결하셔야할듯

<https://github.com/vercel/next.js/discussions/11957>

위에 올리신 코드에서 쿼리 두번쓰는 부분만 getDataFromTree 로 갈아끼울수 있겠네요

근데 integration 방법이 참... 뭐랄까

~저거 CM-safe 한가~ 이건 의미가 없군요 apollo client 가 통째로 CM incompatible 하니

<https://graphql-korea.slack.com/archives/CN13FD736/p1610517370249900?thread_ts=1610516011.247500&amp;cid=CN13FD736>

우선 지혁님 답변에 대해서 생각해봤는데, `gerServerSideProps` 에서 데이터페칭한 응답을 컴포넌트에 주입하는 식으로 하고, 데이터 페칭을 위한 인풋이 인터랙션으로 바뀌는경우 url 패스를 변경하는 식으로 하면, 클라이언트 사이드에서 쿼리를 중복으로 작성하는 일을 없앨 수 있을 것 같습니당.
현재 고민은 이런방식으로 했을 때, 클라이언트 사이드에서의 뮤테이션 이후의 캐시스토어 업데이트를 반영할 수 있는가? 인데 제 지식으로는 내에서 생각해보면 안될 것 같아용 :disappointed: 페이지단에서 아폴로 캐시스토어에서 데이터를 가져오는 것이 아니라 서버사이드에서 주입한 데이터로만 렌더링을 하고있어서 이렇게 생각이 듭니당!

아폴로 캐시 스토어 하이드레이션을 위해서 `getServerSideProps`에 의존하는건 아닙니당! 그래서 getDataFromTree를 쓸 필요가 있을까? 생각이 들어용...

아아... 혜성님 말씀을 이해는 했는데... 오우...

`getDataFromTree` 를 사용해서 아폴로 캐시 스토어 데이터를 찾아서 컴포넌트의 주입해주는걸 말씀하시는거죠?? 그래서 HoC로 만들어서 하는거구요... 이해는 갔는데....

제가 최신버전의 Next.js를 실제 대 고객용으로 쓰고있진않아서 ㅠㅠ 뭔가 인사이트있는 답변을 드리기가 힘드네요 ㅋㅋ

많이 구리네요 ㅋㅋㅋㅋ 네비게이션할 때 preloading 때문에 렌더링까지 할 필요가 없긴 할건데

디스커션 참여한 사람들이 이렇다할 API 제안을 안하는게 놀랍긴한데...

저라면 이런식으로 디자인 할거 같아요

```const MyQuery = makeQuery(graphql`
  query MyQuery { ... }
`);

function MyComponent({ preloadedData }) {
  const { data } = MyQuery.use(...);
};

export default MyComponent;

export async function getServerSideProps() {
  const preloadedData = await MyQuery.preload(...);
  return {
    props: { preloadedData },
  };
};```

저도 Next를 안쓰는지라 의존성 주입 어떻게 할지는 문서를 죄다 뜯어봐야 알듯

우선 혜성님과 지혁님의 답변으로부터 뭔가 영감을 받긴 해서 시도해보고 올게용 :slightly_smiling_face: 감사합니다!

두분 모두 화이팅입니다 ㅎㅎ Apollo + Next.js 연동하는 방법, 사례로 담에 발표하시면 좋겠네용 ㅋㅋ

+ GraphQL 레이어 자체에 타입이 존재한다

+ 데이터 요구사항이 클라이언트에 살아서 빠른 개발이 가능하다

<@U01DQ1RSS93> GraphQL 레이어 라는게 어떤건지 혹시 알 수 있을까요??

클라이언트와 서버사이 어딘가에 GraphQL Schema 로 추상화된 계층이라고 보면 될 것 같아요

그냥 GraphQL 스펙 자체에 타입이 있다는 장점으로 생각하셔도 무방합니다

감사합니다 조금 더 공부해보겠습니다!

이거 몇마디로는 끝나지 않을 질문인거같네요 ㅎㅎ 저희 밋업 유튜브 한번 보시죵 ㅎㅎ