Why infinte-query? react-query의 캐싱 기능이 없이 무한 스크롤을 구현했다고 생각해보자! useState에 서버에서 받아온 데이터를 쌓아나갈 때, 데이터에 좋아요 버튼이 있어서 클릭(좋아요 API 호출)한다고 하면 화면에 바로 반영이 되지 않을 것이다. 새로고침을 해서 API를 차례로 호출하면서 다시 좋아요가 눌린 요소까지 내려가야 좋아요가 눌린 상태를 확인할 수 있다! 좋아요가 눌린 최신 서버 데이터가 아니기 때문이다! 하지만 react-query는 useMutate로 서버의 데이터를 변경하는 API를 호출(좋아요 버튼 클릭)해서 캐싱 데이터를 초기화해서 다시 서버에서 최신 데이터를 받아올 수 있다! → 좋아요가 눌린 서버의 데이터를 바로 받아와서 즉시 좋아요가 눌렸다는 표시를 ..

문제점 useQuery나 useMutate, useQueryClient 등 react-query에서 자주 쓰이는 훅을 모듈화 시킬 때, 아래처럼 컴포넌트나 Custom Hooks 밖에서 export 시키면 오류가 발생한다!! import { useMutation, useQuery, useQueryClient } from "react-query"; import api from "../utils/api"; export const queryClient = useQueryClient(); export const { data, isSuccess } = useQuery(["my_board"], () => api.get("/api/board") ); export const { mutate } = useMutation..

Why? UX적 관점에서 생각할 때, 아래처럼 로그인하지 않은 사용자가 인증이 필요한 페이지에 접속하려고 할때 로그인 화면으로 넘어가서 로그인을 마친 후 다시 원래 가고자했던 페이지로 돌아오는 것은 사용자의 편의를 위해서도 매우 중요하다! 만약 인증된 사용자만 사용할 수 있는 페이지를 사용하려고 할 때, 로그인을 하지 않은 상태이거나 jwt-token이 유효하지 않으면 로그인 화면으로 가서 로그인에 성공하면 다시 원래 화면으로 돌아올 수 있게 리다이렉트하게 할 수 있게 Navigate 컴포넌트(react-router-v6)의 url에 쿼리 파라미터로 기존에 사용하고자하는 페이지의 url을 넘겨주자. 만약 로그인이 된 상태라면 기존에 이용하고자 하는 페이지의 컴포넌트를 리턴해서 렌더링한다. 즉, Priva..

Why? 인증이 필요한 서버로 데이터를 보내거나 조작하는 API를 호출할 때 보안을 위해 interceptor로 요청을 가로챈 후 HTTP Authorizaition 요청 헤더에 jwt-token을 보내서 서버 측 해당 API에 요청을 하기 전에 서버 측의 미들웨어에서 이를 확인한 후 검증이 완료되면 API에 요청을 하게 한다 클라이언트가 jwt-token을 저장하는 위치는 매우 많겠지만 아래 예시에서는 localStorage에 있다고 가정하자!! axios interceptor import axios from 'axios'; import store from "../redux/configStore"; import {jwtUtils} from "./JwtUtils"; const instance = axio..

Why? 게시판에 글을 등록할 때, 사진이랑 제목, 글의 내용과 여러 데이터를 form-data에 보내야 할 경우가 있을 것이다! form-data에 위처럼 키를 여러개 만들어서 모두 넣을 수 있지만 아래처럼 파일 객체 따로 나머지 데이터 전체를 객체에 보내서 서버에서 파싱하게 쓰게 하려면 아래처럼 나머지 데이터를 stringfy해서 보낼 수도 있다! 아래처럼 객체를 JSON.stringify해서 나머지 데이터를 보내자! const handleSubmit = async () => { const formData = new FormData(); formData.append("files", image.image_file); formData.append( "board", JSON.stringify({ title..

recoil 페이스북에서 출시한 React 전용인 전역 상태 관리 라이브러리이다. 공식 레퍼런스 ↓↓↓ https://recoiljs.org/ko/docs/introduction/motivation 동기 | Recoil 호환성 및 단순함을 이유로 외부의 글로벌 상태관리 라이브러리보다는 React 자체에 내장된 상태 관리 기능을 사용하는 것이 가장 좋다. recoiljs.org 기존 전역 상태관리 라이브러리의 문제 기존에 사용되었던 Redux나 Mobx가 성능 자체에 문제가 있던 것이 아니라 오히려 Flux 패턴을 기반으로 안정적이지만 여러가지 문제가 존재했다 React 전용 라이브러리가 아니기에 React가 볼 때 Store가 외부의 어떤 것이며 동시성 모드를 구현하기에 호환성이 떨어진다 복잡한 보일러 ..