https://facebook.com/groups/graphql-kr logo
Join Slack
Powered by
`interfaceType` 으로 선언하고 각 타입내에서 `t.implements` 로 때...
# 잡담
t
interfaceType
으로 선언하고 각 타입내에서 
t.implements
로 때려버리면, 해당 
interfaceType
내 리졸버 첫번째 argument(
parent
? 
root
?) 에 Union Type으로 잘 들어오더라구요 ㅋㅋ 신기했어요
Copy code
objectType({
  name: 'User',
  definition(t) {
    t.implements('Node')
  },
})

objectType({
  name: 'Post',
  definition(t) {
    t.implements('Node')
  },
})

interfaceType({
  name: 'Node',
  definition(t) {
    t.id('id', {
      resolve(parent) {
        // parent: User | Post
      },
    })
  },
})
h
그 얘기했던 케이스는 실제로 다형성 타입을 제공하고 싶은게 아니라 그냥 필드 로직을 공유하고 싶을 때 였어요
예를들면 user field 일때
t
넵 ㅋㅋㅋ 어떤 뜻이신지 이해했어요
흠... 잠시만요
h
user(id: “id”) 랑 post.author 리졸버가 있는데
이 둘은 root context 에 따라서 타입이 약간씩 바뀌지만
내부로직이나 쿼리 빌더는 많은 부분 공유하도록 작성할 수 있거든요 그럼 그냥 서브 타입 처리하는 리졸버 구현 하나만 작성하고 같이 쓸 수 있겠죠. 테스트 케이스는 달라지진 않겠지만 짜잘한 구현 중복을 줄여주는 경우가 많아서
t
맞아요 ㅋㅋㅋㅋ 이해했어요
h
root나 arg 타입 가드 하면서
이게 된다면 확실하게 약을 팔고 다닐 의향이 있습니다
ㅋㅋ
t
흠... 저는 웬만하면 Resolver 함수를 떼내서 테스트를 하진 않는거 같아요. 뭔가 엄청나게 공통으로 쓰여진다면, 응집력있게 함수로 빼서 Unit Test를 할텐데. 스펙도 계속 바뀌고, 제가 하는 프로젝트가 여러명이 Contribution하는거다보니 함수로 빼다보면 타고타고해서 처음 프로젝트 clone하신분이 이해를 못하시더라구요 ㅋㅋㅋ 그래서 로직에 Duplication이 생기더라도 웬만하면 함수로 안묶습니다. DataLoader에 들어가는 Batch 함수나 context로 authorize하는 부분이나 몇가지 모델에서 테스트만 하는거같아요
물론 제가 초보라 ㅋㅋㅋ 테스트를 잘 못해서 그런것도 있습니다
그치만 혜성님이 어떤걸 하려는지는 100% 이해합니다 ㅋㅋ
h
뭐 저도 duplication 하는 쪽이 맞는 방향이라고 생각하긴 합니다. 이건 뭐 엣지케이스죠
👍 1
그냥 “허용이 안되는” 거 자체가
t
ㅋㅋㅋㅋㅋㅋ 맞아요
h
요리조리 메타프로그래밍 하기는 좀 어렵겠구나 라는 인상을 줬어서
Open in Slack
PreviousNext
Powered by