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

GraphQL Korea

CRA 에서 린트를 따로 안 돌려서 1번만 돌텐데.. 이건 어떤 걸 말씀하신건가요? 다른 설명은 감사합니다!

<@UN0GLRW14> apollo 말고 relay를 쓰는 이유는 무엇인가요???

Fragment 지원이랑 컴파일러 너무 좋아서요 ㅎㅎ Pagination도 좋구, 가비지컬렉션도 스마트하구요

그냥 레퍼런스가 없다 뿐이지 모든면에서 더 나은거같아요 ㅎㅎ

relay를 한번 모험해봐야겠어요 ㅎㅎ

네 둘다 써보시구 한번 맛만 보시면 다르다는걸 느끼실꺼에요.

타입스크립트 레벨에서 암만 노력해도 사용자 코드를 자동 생성해주거나 이럴 수가 없잖아용 매크로같은게 없으니

아 원래 TS 군요 어쩔 수가 없네여

네. 흔한 일이지만 코드베이스가 타입스크립트인것과 타입스크립트 사용자에게 행복을 주는일은 원래 완전 다르죠 ㅋㅋ

하긴 라이브러리 쓰는 사용자 코드에 개입할 수 없으니..ㅋㅋ 답변 감사합니다. :man-bowing:

DI 는 항상 좋죠. 거의 대부분의 리액트 프로젝트에서 이미 자연스럽게 활용되고 있고요. 하지만 DI를 위해서 클래스를 도입하는건 조금 부자연스럽게 느껴집니다. 특히 리액트에서는 외부에서 별도의 라이프사이클을 가지는 객체를 동기화하는게 비용이 있다보니 MV* 모델보다는 Elm-ish 모델이 더 잘 어울립니다.

MV* 모델을 차용한다고 해도 저라면 Rx 같은걸 채택하지 일부로 클래스를 하나 만들거같진 않네요

inversify에 대해서 잘 모르는데 싱글톤 객체를 DI하는것과 전역 스코프를 참조하는 것과 차이점이 있나요?

같은 얘기 아닌가요? 캡슐화 차이인듯

사실 DI 하겠다고 inversify 나 nestjs 같은걸 쓰는건 잘 모르겠어요

앵귤러 같은건 아예 프레임워크 퍼스트파티 제공이니 그러려니 하는데

저는 개인적으로 클래스보단 고차함수쪽을 선호하는 편이라

그냥 `interface A` 로 표현되는 DI가 가장 단순하다고 여기는데 마이너 의견일지도 모르겠군요

자바를 쓴지 너무 오래되서 그런가

스프링 느낌이 물씬 나는 물건이네요.

네 사실 DI랑 클래스는 별로 연관이 없어서 저는 저런거 볼때마다 이미 잘 하고 있는데 굳이...? 같은 인상을 많이 받긴 하는거같아요 ㅋㅋㅋ

특히나 이미 그런 부분을 제공하는 프레임워크가 있는 경우 (예시: React, Express) 저렇게 일부로 싱글톤 내지는 별도의 라이프사이클 만들어서 관리하는게 오히려 기존의 깔끔한 의존성 구조를 깨먹는 경우가 많죠

새 프레임워크 만들 때 빌딩블럭으로는 괜찮을지도요 :slightly_smiling_face:

의견 주셔서 감사합니다!
말씀주신 내용 중 Elm-ish 모델은 어떤 걸까요? 제가 아직 모르는게 많네요:smiling_face_with_tear:

대충 얘기하면 Flux 나 Redux 같은거요 ㅋㅋ

자세히 알고 싶으시면 The Elm architecture 를 찾아보시면 됩니다

이미 지난 얘기 같지만 DI 가 필요하다고 React 환경에서 inversify 같은걸 가져다 쓰는 것보단 이미 있는 Context Provider 를 쓰는 게 훨씬 낫다는 생각이 들어요.

MobX 처럼 통합만 잘한다면 꼭 안쓰리라는 법도 없긴 하죠 ㅋㅋㅋ

근데 그게 MobX 가 만들어진 맥락등을 생각하면 무진장 힘든일이기 때문에 굳이 안하는거기도 하고요

inversify를 쓰는게 큰 의미가 없다는데에는 저도 동의합니다! (그냥 ioc container모양새를 잘 갖춰서 context로 넣으면 되니까요) 그냥 코드 없이 어떤 형태의 코드작성을 하려는지 의미를 전달하려다 언급했는데 물어보려던 내용에서 벗어나게 되었네요:upside_down_face:

질문의 주요 포인트는 저 툴의 사용여부보단 class를 이용해서 ood형태로 상태관리하는 모양새가 어떤가에 대한 질문이었어요

다만 mobx 내지는 mst 정도가 적절한 예시라고 생각해요

두둥.. 이렇게  훅가는군요 ㅋㅋ

오 이거슨.. 예를들어 쿼리에 100개의 아이템이 달려온다고 하면 100개가 다 오지 않아도 1개씩 올때마다 클라에서 점진적으로 렌더가 가능하다는 것일까요

그리고 아폴로 3.5에서만 가능하고용

그냥 GraphQL transport 스펙이에요.

이거 시도해봤는데여, 이렇게 해도 요청이 완료되면 re-render 가 발생해서 백그라운드에서 도는 효과를 내지는 못하네요…

일단 쿼리는 다음과 같이 나뉘어있습니다.

1. A~Z 이름을 가져오는 쿼리
2. A~Z 매개변수를 바탕으로 각 데이터를 가져오는 쿼리
제가 시도한 방식은,

1. A~Z 이름을 모두 가져오고 A의 아이디를 매개변수로 넘겨 데이터를 가져와서 보여준다.
2. 1이 완료되자마자 B~Z 아이디를 매개변수로 넘겨 데이터를 가져오는 쿼리를 실행한다.
여기서 이제 2가 완전한 백그라운드로 돌아야 하는데 렌더링이 발생합니다.

아폴로 클라이언트를 직접 쓰면 해결될 것 같기도 하네여 시도해보고 오겠습니다

일단... "백그라운드"는 어떤걸 의미하고 "렌더링은 왜 피해야" 하나요...?

1. 백그라운드란 렌더링에 영향을 주지 않으면서 서버 요청이 진행되는 상황을 말합니다.
2. 렌더링을 피해야 하는 이유는 UX 에 방해가 되기 때문입니다.

뭐 어떻게 해결하긴 했는데여, best practice 인지는 모르겠네여 ㅋㅋㅋ 비동기로 불러온다음 ref 에 저장해두고 B~Z 선택할 때마다 state 업데이트 하는 방식 썼습니다

리렌더링이 정말 UX를 해치는지는 여러번 생각해봐야 합니다. 말씀하신 케이스는 "렌더링만 나중으로 미룸" 인데 그렇게 했을 때 얻는 것이 있나요

그리고 일반적으로 Background task 라고 불리는 것들과 정의가 좀 달라서 질문을 잘 이해하기 어려웠어요

기존: A~Z 를 전부 요청한다음 렌더링
이후: A만 렌더링 한다음 백그라운드에서 B~Z 요청

이렇게 해서 초기로딩 속도 개선을 위함이었습니다!

네 원래 하고자 하셨던게 쿼리패스를 분할하고 불필요한 부분을 defer 하는 처리로 이해해서요

그럼 background 에서 실행이 아니라 그냥 실행을 미루는것이고

이후 로딩된 것을 "미리" 렌더링 하는 것이 초기 렌더링을 느리게 하는 요인이 아닐거같고요

애초에 다 비동기 작업이므로..

뭐 우선순위 문제가 있다면 실행을 requestIdleCallback 같은데 위임하는거 정도는 있겠지만

로딩된 것을 “미리” 렌더링한다기 보다 요청이 완료되지 않았을 경우 “로딩 바” 를 계속해서 렌더링하기 때문에 사용자 입장에선 느리게 판단하는 거인것 같네여

즉, “로딩 바” 를 렌더링하는 시간을 줄이는 게 목표였습니당

로딩바 따로 돌게 하면 되잖아용

UI 레벨 블로킹이 모든 요청 단위로 일어날 필요는 이제 지우셨으니까

로딩바를 애초에 보여줄 필요가 없죠

첫 요청이 완료되지 않았을 때 로딩 바를 보여줘야 합니당

근데 defer 된 요청에 대해서는 말이죠

그니까 그거 때문에 ref 를 쓰는게 이상하다는 지적인데요

(ref를 그런 용도로 쓰는건 정말 이상하게 느껴져요)

ref 없이도 할 수 있는 일이고 (일반 state 로)

넴 defer 된 요청은 2가지로 구분되는데,

1. 사용자가 버튼을 클릭했을 때 데이터가 없으면 로딩 바를 보여줍니다.
2. 사용자가 버튼을 클릭했을 때 데이터가 있으면 데이터를 보여줍니다.
ref 의 용도는 DOM 컨트롤 또는 렌더를 일으키지 않는 변수에 사용해서 썼구여

일반 state 로 하게 되면 렌더링이 발생하게 되지 않나요?

네 그럼 그냥 state 쓰면 되고 리액트 리렌더는 신경쓸게 아닌거 같습니다

리렌더가 실제로 일어나야 하기 때문에 일어나는거고

ref 로 그걸 막을 수 있다는건 오해입니다

일단 그렇게 쓰는게 concurrent safe 하지 않을뿐더러... 이해하기도 어려운 코드를 만들어서

오해라기 보단 의도인데요, ref 가 실제로 렌더를 일으키진 않지 않나요?

위에 정리해서 적어주신게 상태에 따른 UI 변경을 얘기하신거잖아요

즉, 렌더링을 인터랙션 발생했을 때로 늦추기 위함이에요, 서버에서 요청 완료되도 렌더링 안되게 말이죠

ref를 쓰던 아니던 동작의 차이가 없죠

:thinking_face:  근데 state 를 쓰면 인터랙션이 발생하지 않아도 렌더링이 발생하는데요?

상태 변경에 따라서 리액트 컴포넌트 렌더링 하는 부분의 코드가 다시 호출되는데요 를 의미하는 거라면 그건 자연스러운 현상이므로 막을 필요가 없고요

그걸 막는걸 React에선 권장하지 않습니다

음 state 로 되나 확인해보고 올게영

state 로 해도 되는군요 왜이리 잘못 알고 있는게 많은건지… 감사합니다!

아름답네요 ㅎㅎㅎ 다음번에 써봐야겠네요

전 안쓰는데 라이브러리 프로젝트는 종종 있더라고요.

근데 CRA 프로젝트면 번들 기준으로 하기보단 Lighthouse 기능 쓰시는게 낫습니다

네 거의 라이브러리쪽만 하는 느낌이긴 하더라고요 Lighthouse를 한번 알아봐야겠네요! 감사합니다

```targetList.map(target =&gt; {
  if (target === null) return null;
  const { val1 } = target;
  // 여기서 map
})```


간단한거라면 optional chaning을 이용해서
target?.val1로도 가능할것 같아요.

이 경우가 최선이겠군요 감사합니다. 배열 메서드 추론안되는건 짜치는군요

null 있는 언어는 어쩔 수 없습니다. 싫으면 Option 모나드를 쓰시는것도 방법

저건 추론이 올바르게 된거고요

추론이 바르게 된 거라 더 힘들군요 ㅋㅋ 감사합니다

```type Node = {
  id: string,
};

type Edge&lt;NodeType extends Node&gt; = {
  node: NodeType,
};

type Connection&lt;NodeType extends Node, EdgeType extends Edge&lt;NodeType&gt; = Edge&lt;NodeType&gt;&gt; = {
  edges: EdgeType[],
  pageInfo: PageInfo,
};

type NodeTypeFromConnection&lt;ConnectionType&gt; = ConnectionType extends Connection&lt;infer NodeType&gt; ? NodeType : never;

function extractConnectionInfo&lt;ConnectionType extends Connection&lt;unknown&gt;&gt;(connection: ConnectionType): { nodes: Array&lt;NodeTypeFromConnection&lt;ConnectionType&gt;&gt; } {
  ...
}```

오 감사합니다 한번 해보겠습니다!

타입스크립트 질문은 재현되는 예제를 TypeScript Playground 에 같이 올려주시면 좋아요

이거 해봤는데 `Connection&lt;unknown&gt;` 에서 에러가 나네여 ㅠ

Node 의 제약조건을 충족하지 않는다고 하네요

<https://www.typescriptlang.org/play?target=99#code/C4TwDgpgBAcgrgGwQQwEYIgHgCoD4oC8U2UAPlAHaIJlRwUAmEAZgJYUQMDcAUD+8AgAnZsgDG0AArIA5hACSFZgHsoAbx5QoAC2QBnGBAAewaXIBcUVMuUZkFXloiMAwnCF7lQgPyX4SNAxMPWAhdhlcXgBfPgFhUQkoF2UKDjFgVhTMAFEGOXwNLTBZBSVlXygzUpVHKE45PQr-FHQsXPyAbQBdaNiKQRFxKWQPTgAlCD1EYEwYZSYCzR19QxMqy2tbCHta5wY3Dy9LELCKGVqKecm-K+7enmMwL2AoMRSQqGLR5NSIdMyKIQoDk8tBjIJGHp1JQrhV6ABrS4Ad0BUVwAApCnVQXoADRLYpyRQqfFRSw-NIZLLtCC4ACUlmkowYEymCBmNI6AHJLkwuV18ARFlo3hQPmplgZwVUgaIEHoILi6q53J4hFAokDCdVVN5vOoorVRR9eZMgfVJt4AHTMFDAACyyDA6PRFrphHwFutpqgeqg3XdfrufC0QggwHcgKxWl0UrWJXxWicKsOQksewOat9+q5XMTSdNeKWhp4JaAA|https://www.typescriptlang.org/play?target=99#code/C4TwDgpgBAcgrgGwQQwEYIgHgCoD4oC8U2UAPlAHaIJl[…]gwHcgKxWl0UrWJXxWicKsOQksewOat9+q5XMTSdNeKWhp4JaAA> 이렇게 하면 되긴 하는데 `node` 가 `undefined` 도 포함해서 함수 사용하는 입장에선 `undefined` 를 필터링해줘야 하네요. 리턴값 `node` 를 `undefined` 포함 안하게 하는 방법이 있을까여

&gt; Node 의 제약조건을 충족하지 않는다고 하네요
그럼 Node 를 넣으면 되죠

&gt; 엣지가 왜 nullable 이여야해요?
실제로 nullable 이에여

&gt; 그럼 Node 를 넣으면 되죠
이게 어떤 말씀이신가요? 노드의 타입은 엣지를 받아서 추론하는건데

실제로 nullable 이면 필터하는건 당연한거 아닌가요

뭘 하고 싶으신건지 잘 모르겠어요

그래서 저 필터링을 첨부한 playground에서 `flatMap` 으로 해주고 있습니다

```const nodes = edges?.flatMap((edge) =&gt; edge?.node ?? []) ?? [];```

`pageInfo` 랑 `edges` 를 받아서 `hasNextPage`, `endCursor` , `nodes` 를 가져오는 건데 `edges` 안에 들어있는 노드의 타입을 추론하려는거에여

그럼 답은 이미 위에 적어드렸는데요

<https://www.typescriptlang.org/play?target=99#code/C4TwDgpgBAcgrgGwQQwEYIgHgCoD4oC8U2UAPlAHaIJlRwUAmEAZgJYUQMDcAUD+8AgAnZsgDG0AArIA5hACSFZgHsoAbx5QoAC2QBnGBAAewaXIBcUVMuUZkFXloiMAwnCF7lQgPyX4SNAxMPWAhdhlcXgBfPgFhUQlYZSZ1TShWBksQsIoZaNiKQRFxaABRBjlMGGSIbHBoY0FGPSSmfA0tChq-GrrIfP5C+JKoF2UKDjFgVnHMcrk+hpNnBhb5rGq29rSwWQUlZV8oM32VRyhOOT0j-xR0LHXF3ABtAF0B0EhWiAAxIWUALbrOYVWr1fBER71C7LZpQYHsZjCb5PKDeFHQywcABuwl4gyKCSkyA8nAAShA9IhgCCFtDGis1qCqjVcNstLoDI0TpZrLYIPZzis3B4vFlQuFzl0mHoekw-oDgVDIC93jwYjxjGAvMAoGJxiEoLtSWMJhApjMKIQoLSwV8GXDgZsIGyABQdC6gvQAGh2e0UKl9UUspsm01mypdAEpLNJSQwKVSEDTIxD2XqDbq1Dp9IYTCdraIEHoIN6Lq53J4hFAotbdnIA6pvOi1FFzvqKIbpZTra7LpTvAA6ZgoYAAWWQYFdfdBUcI+H7Q+7aPRbznzaga6g+m+CqBzNTb3xWiEEGA7itHo5ue5e19WicFdFQkswsrXhXUAA5F-7w-uz6aRtuq+LGiWobmuGFDumk-aypuaRaFe-7dKkD7oekmTfsgqzML+iEYcglhfvoDB4X+GFWJYACMFEPjE6EMVArxBlGQA|https://www.typescriptlang.org/play?target=99#code/C4TwDgpgBAcgrgGwQQwEYIgHgCoD4oC8U2UAPlAHaIJl[…]mTfsgqzML+iEYcglhfvoDB4X+GFWJYACMFEPjE6EMVArxBlGQA>

노드 인터페이스는 왜 있는건가요?

실제 `node` 값에는 `id` 말고 다른 값들도 있어서 저렇게는 추론이 안되더라고여 그래서 `type Node = unknown` 으로 재정의하니 되네요. 감사합니다. :man-bowing:

다른값있어도 돼요 여기서는 unknown 이랑 역할이 동일해요

<https://join.slack.com/t/react-korea/shared_invite/zt-4jcwqkgg-DRdtUSvV8Pas984ctcJw8w>

딱히 활발하지는 않은데 그래도 아는건 여기라 ㅎㅎ

근데 정보는 많이 없네요..ㅠㅠ

GraphQL Korea가 더 강력하신 분들이 많아서 ㅎㅎ 요 채널에 남기시는게 도움 얻어가시는데는 더 좋을듯합니다 ㅋㅋㅋ

그냥 여기서 이야기나누시는 게 나을 수도 ㅎㅎ

<https://www.typescriptlang.org/play?#code/C4TwDgpgBA4gTgQzACwIoBkDKBjZEC2CUAvFAK4B2A1hQPYDuFA3AFAuiRQCiAHhNmWAIARgBsIAEQCWcfsCkA3COlrYE82hRIsoUAD5QA5KgCqXAEoBNQzv1GAsiYAqAQScBJAPIA5G7oOGmCYAQpgAwubuAAoePn52hgBi7lzoEvEBieYuMPZc3k4A+hJcyd7usb62mdm5+UWYUeZcLunVRu7e6J1chVk5eQWGrOzg0E5jmCAAzsAE0rLY8koqahpaxO2BYQASXPYuGUbhLugu5keGnsEAUlxhTpfJqRLFpZ0VXlX+RucwJoMiiUyp84ltOk4LIkXGEuJcTOUwT9DPkAZdUfZCgA1U5mS6dKLOQrXO4PfHeQlFZ5pN4gyrDNgcaALOSKZSqdRSTTaH68fiCETiFlLNmrTmadoTSBTWbzGSslYc9YjCA8MC0ODAKBSChzOAAMwQ2GZ8pFSgAPMLlhBvAh8NBVXMKAATaZQWZwHUAcwAfFAAN62JkSCD66YALigAANnabrVAAAIAEn9VrZtvtAF8oNyU2nFWsuRRM1HWLpgIgKNN9Rr7XAABTTXAEBCR+BINBYZuEACUbcQKAwODwhFYmbY2E0sygscW1sj+Yg5sMYDIYik2EMftIgfLYxDYcjhlnCugCdX6+wOa01NewI+9IANEHK9XaxA4JGmyOiMQ-d+W2fTMgA|https://www.typescriptlang.org/play?#code/C4TwDgpgBA4gTgQzACwIoBkDKBjZEC2CUAvFAK4B2A1hQPYDu[…]cjhlnCugCdX6+wOa01NewI+9IANEHK9XaxA4JGmyOiMQ-d+W2fTMgA>

음..? 이걸 왜 template literal type 으로 ㅋㅋㅋ

이렇게는 해줬는데 `FIELD_DEFINITION | OBJECT` 같이 해줄 수도 있을까요?.?

타입에 대한 재귀를 말씀하시는건가요?

그냥 저걸 다 묶어서 돌리면 스펙이랑 호환되지 않을거기 때문에

타입이 다 세분화 되어야 할거에요

그냥 재귀돌리는건 해서 보여드릴게요

감사합니다 ㅎㅎ 제너릭 타입에 대해서는 예쩐에 Awaited 처럼 시도하면 대략 감이 잡힐듯 한데 지금처럼 타입이 된 경우에는 어떻게 해야 하나 고민중이던 찰나였습니다

아 왜 playground 는 vim 입력도 지원 안하나요

tmi: 여러개에 대한 추론은 just for fun 인데 지금같은 형태를 쓴건 디렉티브에 쓸 수 있는 로케이션이 뭐뭐 있는지 아직 몰라서 만들게 되었습니다

음 근데 팩토리얼이라서 이대로는 안될거같은데 ㅋㅋ

재귀 깊이가 50까지밖에 안내려가요

일단 너무 기다리시면 재미없으니

몇가지 기본 세트를 먼저 제공해드리겠습니다

<https://www.typescriptlang.org/play?#code/C4TwDgpgBAEhCGATAPAFQK5gDbQgD2AgDtEBnKAJwUQHsisQp4iQBtAXQD4oBeKDbBFYByHEQDmwABbD2UfIRLkADFAD8UIhABuEClABc-TDlbL2AKFCR+8AJZY0J3AWJlK1OgyjoiAayIaAHciDm4+ARx5VyUoVmYQNQAaKAA6dLsiADM9Wwc5DVR7LENNHT0AbitwaAARChowADE7ClJgJ0FoxXcqJC9GXwDg0K5eYy6FN3I+2npGeJZktIzs3IBVAqh10tZ01MiIdirraABBMEgSTqip2NmBn39AkI4UgElCAFtwuP3Dj7fY7VGwAKRomRuLh6M088yg7QomXEbygAGUIJAKPBgDR9Hd3IjkSkAEoQUjoLDAbrTBHAJEScbCYS-ADeFigHgpVKMZO5wCSHLpmKM4MhQs59UaLTaHUOnEFnM5GKxOLxiqVfMp1IJ5GZ6igAAMACSsuBIKGcAC+htKJtZWqpVtNKr0aoozrN1EtNqFnAsVtYhxEYkkMjkuqgqg0wio-OEpWE7UxsiqFgAxnR2vwamiQMmvrVWhB08A7LoADI0dM4ux0casIXCNEAYRgAFEALJnYQa5sts4Vs4k3tNgDyACFQe2W6hR5zhE13u2K7UAPq1dtLgBy71Q7zH2-nUGEw4A4utO+3t6gN1v3rv94fj8IH6h2ySmmcW+2X+td8+fbXpeL7AZ2a4AGqDusv59g+AAK6y3pO06zi+CFIWuS4ruum47nuB5HoKcjwOQmZEO0Jw1DmkB5gWRZUKW5YQFWNZlvWfCnDQWQ0RAdHfAxJZlpW1a1nQrBEOgXwAEZ6MCILnOMYpEMgXE8agub5gJxZMSJbF1kQKQJgAPienAVEAA|https://www.typescriptlang.org/play?#code/C4TwDgpgBAEhCGATAPAFQK5gDbQgD2AgDtEBnKAJwUQHsisQp[…]OgXwAEZ6MCILnOMYpEMgXE8agub5gJxZMSJbF1kQKQJgAPienAVEAA>

이것만 있어도 감잡고 푸실 수 있을 것 같아요

• 텍스트 설명: <https://blog.cometkim.kr/posts/typescript-tuples/>
• 다른 예제: <https://github.com/cometkim/cometjs/blob/main/packages/core/src/tuple.ts>

이걸로 이제 원하는 조건식 포함한 재귀함수를 만드시면 됩니다

깊이(차수) 제한 안에서 원하시는걸 다 할 수 있음

&gt; 디렉티브에 쓸 수 있는 로케이션이 뭐뭐 있는지 아직 몰라서 만들게 되었습니다
요건 GraphQL 명세에 다 나와있어용

네네네 볼때마다 들락날락 하게 되어서 움 그냥 북마크를 좀더 자주 보는것도 방법이겠지만요 ㅋㅋㅋ

그냥 validate schema 하면 알려주긴 합니다 ㅋㅋㅋㅋ

인덱스 번호 다루기 위해 산술연산 필요하시면 이런식으로..

```type MakeTuple&lt;T, N extends number, Result extends readonly T[] = []&gt; = {
  0: Result,
  1: MakeTuple&lt;T, N, [T, ...Result]&gt;,
}[Result['length'] extends N ? 0 : 1];

type AddOne&lt;N extends number&gt; = [...MakeTuple&lt;unknown, N&gt;, unknown]['length'] &amp; number;
type Add&lt;A extends number, B extends number&gt; = [...MakeTuple&lt;unknown, A&gt;, ...MakeTuple&lt;unknown, B&gt;]['length'] &amp; number;

type SubOne&lt;N extends number&gt; = MakeTuple&lt;unknown, N&gt; extends [unknown, ...infer Tail] ? Tail['length'] : never;
type Sub&lt;A extends number, B extends number&gt; = B extends 0 ? A : Sub&lt;SubOne&lt;A&gt;, SubOne&lt;B&gt;&gt;;

type Mul&lt;A extends number, B extends number, Result extends number = 0&gt; = B extends 0 ? Result : Mul&lt;A, SubOne&lt;B&gt;, Add&lt;Result, A&gt;&gt;;```


암튼 그냥 코드 제너레이터를 만드시는게 정신건강 + 맥북수명 + 탄소절감에 훨신 이롭습니다

Server driven UI 에 대해서 찾아보세요

<https://deview.kr/data/deview/session/attach/GraphQL%E1%84%8B%E1%85%B5_%E1%84%80%E1%85%A1%E1%84%8C%E1%85%A7%E1%84%8B%E1%85%A9%E1%86%AB_%E1%84%8B%E1%85%A6%E1%84%8B%E1%85%A5%E1%84%87%E1%85%B5%E1%84%8B%E1%85%A2%E1%86%AB%E1%84%87%E1%85%B5_%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%86%AB%E1%84%90%E1%85%B3%E1%84%8B%E1%85%A2%E1%86%AB%E1%84%83%E1%85%B3_%E1%84%80%E1%85%B5%E1%84%89%E1%85%AE%E1%86%AF%E1%84%8B%E1%85%B4_%E1%84%87%E1%85%A7%E1%86%AB%E1%84%8E%E1%85%A5%E1%86%AB%E1%84%89%E1%85%A1_1106.pdf|https://deview.kr/data/deview/session/attach/GraphQL%E1%84%8B%E1%85%B5_%E1%84%80%[…]7%E1%86%AB%E1%84%8E%E1%85%A5%E1%86%AB%E1%84%89%E1%85%A1_1106.pdf>

<https://github.com/parksb/server-driven-ui>

간단하게 폼만 구현하신다면 jsonschema form이라는것도 있습니다
<https://rjsf-team.github.io/react-jsonschema-form/>

혹쉬 오픈소스를 관리하는 팁 아니면 노하우,, 아니면 알아둘만한게 있다면 조언 부탁드립니다 :bow:

<https://news.hada.io/topic?id=5379> 최근에 본 글인데 도움이 됐으면 하네요 ㅎㅎ

<@U012FUYCZ8X> 슬쩍 봤는데 넘 좋네요 ㅎㅎ 굳이굳이 피드백 드리자면

```import { QueryClient } from 'react-query';
import { QueryHelper } from 'react-query-helper';

const queryClient = new QueryClient();
QueryHelper.setQueryClient(queryClient);

new QueryHelper(
  ['user'],
  (context) =&gt; ...
)```
이런 API 보다는

```import { QueryClient } from 'react-query';
import { QueryHelper } from 'react-query-helper';

const queryClient = new QueryClient();

new QueryHelper(
  queryClient,
  ['user'],
  (context) =&gt; ...
)```
이게 더 낫지 않을까요? ㅎㅎ

+ 저라면,

```import { QueryClient } from 'react-query';
import { makeQueryHelper } from 'react-query-helper';

const queryClient = new QueryClient();

makeQueryHelper({
  queryClient,
  models: ['user'],
  fetcher: (context) =&gt; ...
})```
이렇게 했을듯 ㅎㅎ

+ DataLoader를 활용한 Batch Helper도 있으면 좋겠다는 생각을 했어요 ㅎㅎ

프로젝트마다 조금씩 달라요. CMS 의 요구사항은 컨텐츠의 종류와 좀 밀접하게 연관이 있어서

아하..답변 감사합니다!
당근은 공개해주신 소스를 봤을때 prismic을 쓰신거로 보이는데 혹시 특별한 이유가 있으셨을까요?
저희도 사용목적이나 요구사항이 비슷할것같은 상황이라 궁금하네요 (혹시 답변이 어려우신 부분이면 어렵다고 해주셔두 됩니다ㅋㅋ)

CMS 의 모델링 기능이 어떤가가 좀 주요한데요.

Prismic 의 모델링 기능은 상당히 느슨한 문서 형식인데 이게 웹사이트 컨텐츠 관리하는데는 더 낫다고 봐서 선택했습니다.

그러지 않은 경우 예를 들면 뭐 Strapi 같은 도구를 선택했을 경우, API 통합 난이도는 많이 쉬울지언정 최종 컨텐츠 표현과 에디터 제약의 거리가 멀어서 여러 패스로 통합하게 되는데 이게 생각보다 과정이 복잡하고 인지비용을 키워요

에디터가 실제 컨텐츠랑 비슷하게 표현 가능할 수록 컨텐츠 퍼블리셔와 지속적으로 소통하기 좋습니다

물론 컨텐츠가 지속성이 필요하지 않다면 별 의미 없는 고민일테고요

다만 스키마가 느슨하게 정의되는거만큼 통합에 어려운 지점이 생기는데 이건 Gatsby 가 ㅁ많이 해결해주는 편입니다

실제로 PoC 구축하고, 컨텐츠에 참여하는 모든 사람들이 먼저 사용해보길 권장합니다

컨텐츠를 기획하는 사람의 참여가 상당히 중요하고요

예전에 남긴 이 주제에 대한 커멘트인데..
<https://twitter.com/KrComet/status/1325164737932357634>

뭐 암튼 저희도 지금 상당히 많은 컨텐츠 Prismic 으로 관리하지만 그게 전부로 생각하긴 또 어려워요. 예를들면 채용공고 관련 컨텐츠나 폼은 전부 Greenhouse 에서 관리됩니다.

만들고나서도 개발단에서만 지속적으로 관리하는게 아닌만큼 앞서서 검증이 필요하긴 하겠네요
좋은 의견 감사합니다!:+1:

네 개발자용 도구가 될거 같으면 그전에 그게 그냥 단발성 마크업치는거보다 나은게 맞는지 의문이 먼저 생기는게 맞습니다.