nested한 형태의 input을 서버로 쏘는데, 아폴로 클라이언트가 계속 인식을 못하는 이슈가 있었다. 해결 내용 정리해봄 gql 스키마에 이렇게 복잡한 input이 정의되어있다. makeQuantity라는 mutation에 전달되는 형태는 이렇다 이 경우 클라이언트에서 쿼리를 정의할 때 item, zoneList,equation값을 일일이 정의하면 안된다. mutation의 input인 projectId와 indirectInput만 정의해주면, nested하게 정의된 자료형은 전부 알아서 정의가 된다. 실제로 useMutation의 변수를 이렇게 담는다. indirectInput이 배열객체이므로 map을 통해 배열을 리턴해주고, 그 내부에는 필요한 형태의 자료들을 정의하여 담는다.

setTime을 로직에 걸고, mutation call을 실행하고 싶었다 그리고 업데이트 된 데이터가 필요하여 바로 데이터를 받고 싶었다 근데 저리 찍으니 콘솔에 아무것도 안찍히더라 mutation이 계속 자기 데이터를 반환을 못하는 상황이었다 ㅠㅠ 사실 지금 만드는 화면 자체가 같은 링크에서 A컴포넌트->B컴포넌트-> A컴포넌트... 이 렌더링이 계속 반복되다가 마지막에 useMutation을 실행하는 이벤트에서는 정작 다른 화면으로 넘어가는 화면이었다 그러니까 마지막 이벤트에서 데이터를 받기전에 다음 링크로 넘어가는 상황이었다 useMutation자체가 비동기로 실행된대서 .then으로 처리해봤는데 무려 loading조차 false가 찍혔다...뭐지.. 그래서 useEffect로 처리했더니 더 가관이..

데이터를 업데이트 했을 때, 화면에 업데이트가 된 이후 데이터를 불러와야 할 필요가 있다. 기존 API 로직대로면 업데이트 된 데이터를 한번 더 find하여 가져오는 번거로움이 생긴다 (물론 클라이언트에서 처리할 수도 있고, 리졸버 context 처리로도 가능하지만 이건 나중에...) 아폴로에서 제공하는 기능에 대해 클라이언트 관점에서 보자면 아예 find를 새로 하는 refetchQueries메소드가 존재한다 Mutation을 시키고, 업데이트 된 데이터를 무조건 다시 화면으로 가져오게 만드는 것이다. 참고로 얘는 비동기적으로 실행된다. 이를 업데이트가 반드시 끝난 후, 동기 처리하려면 awaitRefetchQueries: true 옵션을 설정해둔다

fetchPolicy는 ApolloClient의 캐싱과 관련된 설정이다. 해당 설정을 통해 client가 캐싱 데이터를 어떻게 활용할지 정할 수 있다. ApolloClient에서는 query방식과 watchQuery방식을 구분하고 있다. query는 단순히 READ에 해당하며, 데이터를 가져오기만 한다. watchQuery는 mutation이 일어날때, 또는 DB상의 update가 일어날때, 데이터를 모니터링 하고 있다가 자동적으로 query를 날려주는 개념이다. mutation의 경우는 변경된 데이터를 가져오기 위해 refectchQuries를 이용하지만 단순 query로 변경된 데이터를 get하려면 watchQuery를 사용해야 한다. fetchPolicy를 통해 DB에 접근하기 전에 캐싱된 데이터를..

참고문헌: www.daleseo.com/graphql-apollo-server-errors/ www.apollographql.com/blog/full-stack-error-handling-with-graphql-apollo-5c12da407210/ Full Stack Error Handling with GraphQL and Apollo 🚀 Most GraphQL layers sit between the application frontend and a constellation of micro-services and data sources, which make them a focal point for error handling. Errors can range from bad user inputs to bac..