
graphql은 사실 rest-api였다?
rest-api의 endpoint를 /qraphql로 만들어서 여러 개였던 endpoint를 하나로 만들고 하나의 큰 함수 안에 세부 기능을 담당하는 함수들을 넣어 사용하게 한 것이 qraphql이라고 한다.
key는 query, value에는 mutation인지 query인지 또 어떤 query인지를 담아야 하기 때문에 항상 post방식인 rest-api인 것이었다.
OPtimistic UI는 일단 성공할 것을 가정하고 기다리는 과정 없이 성공했을 때의 결과를 바로 보여주는 것이다.
optimisticUI의 장점은 유저의 입장에서 빠르게 느껴진다는 것이다.
실제로 처리를 해서 보여주는 것은 아니지만 사용자의 입장에서는 처리 속도가 빠르다고 느끼게 할 수 있다.
물론 위험성이 있기 때문에 사용해도 되는 조건이 있다고 한다.
1. '좋아요 기능'과 같이 단순하고 작업량이 적은 API일 것.
2. 성공 가능성이 높은 API일 것(웬만해선 무조건 성공하는 것).
3. 혹시 실패하더라도 위험성이 적은 API일 것.
이러한 조건을 만족한다면 optimisticUI를 통해 성능을 개선할 수 있다.
useForm에 내장되어 있는 기능이다.
데이터를 등록할 때 버튼을 여러 번 눌러서 같은 데이터가 쓸데없이 여러 번 등록되는 것을 막아줄 수 있다.
useForm을 사용하지 않더라도 버튼에 disabled속성을 이용하여 조건을 걸면 같은 기능을 해줄 수 있다.