투두 삭제할 때 mutation 부분 코드를 강의와 똑같이 // use-delete-todo-mutation.ts export function useDeleteTodoMutation() { const queryClient = useQueryClient(); return useMutation({ mutationFn: deleteTodo, onSuccess: (deletedTodo) => { queryClient.setQueryData<Todo[]>(QUERY_KEYS.todo.list, (prevTodos) => { if (!prevTodos) return []; return prevTodos.filter((prevTodo) => prevTodo.id !== deletedTodo.id); }); }, }); } 이렇게 치면 바로 삭제가 안 되고 새로고침해야 적용이되는데 export function useDeleteTodoMutation() { const queryClient = useQueryClient(); return useMutation({ mutationFn: deleteTodo, onSuccess: (_data, deletedId) => { queryClient.setQueryData<Todo[]>(QUERY_KEYS.todo.list, (prevTodos) => { if (!prevTodos) return []; return prevTodos.filter((prevTodo) => prevTodo.id !== deletedId); }); }, }); } 이렇게 작성하면 바로 삭제 적용이 됩니다. 무슨 차이가 있는 걸까요?? 그리고 강의에 왜 처음 코드는 바로 삭제 반영이 안 되는 건지 궁금합니다 ㅜㅜ!
라우트 가드 학습 중 궁금한 점이 생겨서 질문드립니다! import { useSession } from "@/store/session"; import { Navigate, Outlet } from "react-router"; export default function MemberOnlyLayout() { const session = useSession(); if (!session) return <Navigate to={"/sign-in"} replace={true} />; return <Outlet />; } 라우트 가드에서는 인증 정보 유무만 검사하고, 인증 정보 만료 여부는 별도로 확인하지 않나요? 만약 그렇다면 인증 정보가 만료된 상황에서의 처리 방법이 궁금합니다! 고민해봤을 때 인터셉터 등 별도 로직으로 구현해 다음과 같이 처리할 것 같습니다 접근한 페이지에서 인증이 필요한 요청 처리가 있다면 refreshToken 을 이용해 accessToken 을 재발급 한 뒤 요청을 재시도한다 refreshToken 도 만료되었다면 요청을 취소하고 로그인 페이지로 리디렉션 한다 그런데 이렇게 처리하면 refreshToken 도 만료된 사용자는 인증 정보가 있으므로 요청 페이지로 이동한다 짧은 순간이나마 데이터가 없는 빈 화면이나 깨진 UI를 본다 로그인 페이지로 리디렉션되며 혼란을 겪는다 그래서 라우트 가드에서 만료된 경우 접근을 막아야 되지 않을까 생각해봤는데 매번 토큰 유효성 검증을 수행하면 성능 저하가 발생할 것 같다는 생각을 했습니다 어떻게 처리하면 좋을지 의견을 여쭤보고 싶습니다!
안녕하세요! 항상 강의 잘 듣고있습니다 :) 강의에서 onAuthStateChange 를 사용해서 사용자 로그인 시 세션 데이터가 변경되며 업데이트된 세션이 매개변수로 전달되고, 업데이트된 세션을 스토어에 보관했었습니다 supabase 를 사용하지 않는다면 세션 데이터 변경을 어떻게 감지하고, 스토어에 보관 해야될지 고민해봤는데 세션 데이터를 사용하는 곳에서 직접 저장 / 수정하는 방법 혹은 강의에서 배웠던 persist 와 subscribeWithSelector 를 활용한 방법도 있을 것 같은데 명확한 방법이 떠오르지 않아 강의 내용과는 조금 방향성이 다르지만 질문드리게 되었습니다!
id를 전부 string으로 변경했음에도 계속 오류가 발생해서 ai한테 도움을 요청했더니 create-todo.ts에 header값을 붙이라고 하더라고요! 그래서 해당 파일 코드에 headers: { 'Content-Type': 'application/json',} 를 붙여줬더니 정삭작동하는 걸 확인할 수 있엇습니다. 왜 이 헤더를 붙여줘야 하는 건가요? import { API_URL } from '@/lib/constants'; import type { Todo } from '@/types'; export async function createTodo(content: string) { const response = await fetch(`${API_URL}/todos`, { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ content, isDone: false }), }); if (!response.ok) throw new Error('Create Todo Failed'); const data: Todo = await response.json(); return data; }
타입스크립트 강의를 따로 안들어서 그런데 컴포넌트 별로 props를 넘길때 언제는 구조분해할당으로 넘기고 언제는 그냥 타입만 선언해서 넘기던데 따로 판단하는 기준이 있을까요? CommentEditor 컴포넌트 props 넘길때 {postId}:{postId : number} 과 (postId : number) 의 차이가 명확히 그려지지가 않습니다.
안녕하세요! 강사님이 얘기해주신 부분에서 구현을 다했고, 추가로 구글로그인도 적용시켰습니다! 이후에, 카카오 로그인 관련해서 적용하려고 앱설정 및 AI 도움을 받아 하려했는데, 구현 부분에서 막혔습니다. 잘못된 요청 (KOE205) onebite-log 서비스 설정에 오류가 있어, 이용할 수 없습니다. 서비스 관리자의 확인이 필요합니다. 서비스 관리자라면 아래를 확인해보세요. 왜 에러가 발생하나요? 접기 설정하지 않은 카카오 로그인 동의 항목을 포함해 인가 코드를 요청했습니다. 설정하지 않은 동의 항목: account_email 어떻게 해결할 수 있나요? 접기 앱 관리 페이지의 [카카오 로그인] > [동의항목]에서 동의 항목 설정을 변경하거나, 설정하지 않은 동의 항목을 제외하고 재요청합니다. 이걸 해결하기 위해선 동의항목에 가서 비즈앱으로 전환하는 방법 밖에 없는 지 궁금하여 문의드립니다!
안녕하세요! ui 관련해서 궁금한 것이 있어 질문드립니다. Popover와 같이 radix-ui 와 @/components/ui (shadcn/ui ..?) 있는 컴포넌트의 경우, 어떤 것을 사용하는지에 대한 기준이 있을까요?? PopoverClose 는 @radix-ui 에서 받아오는데, 어떤 것은 @/components/ui 에서 가져와서 사용하고 그래서 혹시나 기준이 있나 궁금해서 질문드립니다!
안녕하세요 정환님 !!! 정환님 강의를 듣다가 state 관리쪽에 개념이 갑자기 섞여서 질문을 하게되었어요 저는 현재 다음과 같은 방향으로 이해를 하고있어요 한 페이지내에서 여러 컴포넌트를 사용할때 간단한 자식 구조에서는 props 를 사용한다. 한 페이지내에서 여러 컴포넌트를 사용할때 3~4 혹은 그이상으로 자식관계가 걸쳐있는 상태에서는 conntext API 를 사용한다. 로그인과 같이 특정 페이지가 아니라 여러 페이지에서 관리가 필요한 state 는 zustand처럼 전역 라이브러리를 사용한다. 제가 이해한 방향이 맞을까요??
안녕하세요 강의 잘 듣고 있습니다 정환님 강의 하셨을 때랑 지금 공식 문서 설치 방법이 달라진 것 같은데 지금 공식문서대로 진행해도 tsconfig.app.json파일과 tsconfig.json파일에 경로 별칭 옵션이 적용이 되는건가요? 아니면 강의 보고 그대로 세팅하면 될까요 https://ui.shadcn.com/docs/installation/vite
안녕하세요 너무 쉽게 설명해주셔서 프론트 왕초보인 저도 아주 잘 따라가면서 강의를 듣고있습니다 ! 이번 파트에서 한가지 의문인점은 저는 예전에 백엔드 서버를 구축할때 소셜로그인이 성공하면 백엔드 내에서 access 와 refresh 토큰을 만들어내서 refresh 를 쿠키형식으로 넘긴 후 소셜로그인 성공 리다이렉트를 바로 access token을 발급받을수있는곳으로 리다이렉팅시켜서 access를 추가적으로 받게끔 구축했었는데, 이번 파트에서 의문인점은 보통 실무에서는 백엔드가 자체적으로 만드는 access refresh 토큰이 아니라 소셜서버자체에서 제공하는 access 와 refresh를 주로 활용하는걸까요 ?
