graphql-code-generator 에서

schema.graphql

의 모든 타입을 생성하는 것 말고 현재 사용하는 쿼리에 대해서만 타입 생성하는 방법이 있나요? 공식문서에는 따로 나와있지 않은 것 같아 질문드립니다. 저장소 discussion 에도 올리긴 올렸습니다..

흥미롭긴한데... 어떤 유즈케이스가 있나요?

Use case 라기 보단 apollo-codegen 에서 넘어와서 어색한 느낌이 듭니다. 아폴로에선 사용하는 쿼리에 대해서만 생성했었거든요. 굳이 모든 타입을 생성하는 이유를 모르겠는? 느낌이에요. 그리고 번들 사이즈가 걱정되긴 하는데 tree shaking 이 알아서 잘 되려나요..

음 사실 어느쪽이냐하면

그게 아주 비싸고 굳이 할 필요없는 작업이긴 합니다

그렇군요.. 스키마가 먼저니까..

그리고 graphql-codegen 은 애초에 런타임 코드는 생성하지 않습니다 (래퍼 제외)

런타임 코드 말고 예를 들어 타입 생성했을 때 2~3천줄 내외로

generated/graphql.tsx

타입 파일이 생성되는데 이걸 어플리케이션 코드에서 사용하는 부분에선 상관없겠죠?

네 뭐 어차피 타입정의에 불과하니... 몇 십만줄이 나와도 상관없긴 합니다

그렇군여! 감사합니당

Graphal codegen 에서 apollo 를 이용한 hook도 만들 수 있어요 ㅎㅎ 저희 내부 스키마가 크다 보니 몇만 줄이 나오는데 vs code가 점점 느려지더라구요. 근데 해답은 아직 찾지 못했습니다 ㅜㅜ

네 파일 커져서 느려지긴 하는데 프리셋으로 쪼갤 수 있습니다.

오 생각해보니 어차피 fragment랑 query에서 나오는 타입만 쓸거니 그렇게 하면 퍼포먼스가 나아지겠네요

https://graphql-korea.slack.com/archives/CN13FD736/p1614828064047900?thread_ts=1614820990.045100&cid=CN13FD736 저도 해당 프리셋 잘 사용하고 있습니당. 🙂

앗 그게 사이즈가 클때 generated graphql.tsx 를 안열어도 다른 파일에서 에디팅중일때도 영향이 있나요? 그건 아니겠죠?

에디팅엔 영향이 없지만 타입스크립트 쓰실 테니까요... 통짜 파일인이상 incremental 하게 처리가 안되기 때문에 타입 정보를 다시 구축하는 과정에서 language service 응답이 지연될 수 있습니다.

호오 꿀팁을 알아가네요,, 어쩐지 codegen 하고 자동완성이 반영되는데 너무 오래걸리더라는