[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
현재 인프런 [코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core강의를 수강 중 입니다. 초반부를 듣고 있는 와중에 @Get() @Get(':id') 이런 데코레이터들의 내부로직에 대한 이해 없이 강의를 따라가는게 맞는건지가 궁금합니다.. 예를 들자면 파람, 바디 등 url에 담긴 데이터들은 파싱을 해줘야하고 http모듈을 쓴다면 직접 로직까지 구현을 했어야했고 express는 미들웨어로 처리를 해줘야 했었는데 nest에선 데코레이터만으로 모든게 알아서 처리 되는 느낌인것 같습니다. 또한 클라이언트로 보내는 응답 또한 return문으로 보내지는 것 또한 너무 추상적으로 느껴집니다.. nest 강의전에 http모듈 및 express를 공부 했던지라 추상화된 코드가 더욱 낯선 것 같습니다. 아직 강의초반이라 데코레이터의 내부로직을 아직 배우지 않는 것인지 아님 배울 필요가 없어서 설명이 없는 것인지 궁금합니다 강사님
실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트
시각적 회귀 테스트 강의의 Storybook 코드에서 play 함수 안에 matcher를 넣지 않고 userEvent.click(...)만 사용한 이유가 궁금합니다. import { userEvent, within } from '@storybook/testing-library'; import AvailableUsers from '@/pages/login/components/AvailableUsers'; export default { component: AvailableUsers, title: '로그인/사용자 리스트', }; export const Folded = { name: '접힌 상태', }; export const Expanded = { name: '펼친 상태', play: async ({ canvasElement }) => { const canvas = within(canvasElement); await userEvent.click(canvas.getByText('⚠️ 사용 가능한 유저 리스트')); }, }; 제가 이해한 바로는, 이 스토리는 storybook에서 아코디언이 펼쳐진 시각적 상태 변화를 보여주기 위한 용도이고, 실제 기능 로직 검증은 Vitest에서 별도의 테스트 코드로 작성하는 방향이라고 생각했습니다. 1. 여기서 play 안에 matcher를 넣지 않은 것은 Storybook을 시각적 상태 확인용으로 사용하려는 의도인가요? 2. 그리고 이 컴포넌트의 동작 검증은 Storybook이 아니라 Vitest에서 담당하도록 역할을 나눈 것으로 이해하면 될까요? 3. 실무에서는 보통 storybook을 어디까지 작성하는지 궁금합니다. - 물론 회사마다 다르겠지만, 강의해주시는 강사님 기준으로 의견을 듣고 싶습니다.
말씀해주신 대로 브라우저의 쿠키 탭에서 데이터를 입력하니, 서버를 재실행했을 때 쿠키가 날라가서 올바르게 테스트를 할 수 없었습니다. Claude 로 확인해보니 headers.set('Set-Cookie', ...) 코드 작성 후 테스트 환경에서 직접 URI 를 입력하여 실행하여 쿠키를 심어보라고 해서 그렇게 했더니 쿠키가 잘 심어집니다! /* src/app/api/test-cookie/route.ts */ // localhost:3000/app/api/test-cookie 로 들어가 직접 쿠키를 입력해야 정상 작동 export async function GET() { const response = new Response('ok'); response.headers.set('Set-Cookie', 'name=kim; HttpOnly; Path=/; Max-Age=3600'); return response; }
강의에서는 리턴문 내에 TodoStateContext.Provider 컴포넌트가 상위에 있고 자식으로 TodoDispatchContext.Provider 컴포넌트가 아래에 있는데 이유가 무엇인가요? 이 둘의 위치가 바뀌면 안되는건가요? 프로바이더 컴포넌트는 하위에 있는 모든 컴포넌트에서 값을 꺼내 쓸 수 있으면 둘의 위치가 바뀌어도 상관이 없는것 아닌가요? 이유가 궁금합니다!
강의 내용을 듣고 생각했을때 , 대부분의 경우 Redis String 보다 Redis Hash 사용하는게 대부분 이득일것 같다 생각이 들던데... 어떻게 사용하고 계시나요 ?? 사실 저는 Redis String 으로 Json 으로 많이 사용했었습니다. 그리고 큰 장애를 경험하지 못했는데요 아무래도 트래픽에 대한 차이인것 같네요
🚨 필독) 질문하시기 전에 꼭 읽어주세요 (10초 소요) 제목을 구체적으로 작성해 주세요 ✅ 좋은 예 : 감정일기장 Home 구현중 xx 이슈가 발생합니다. ⛔ ️ 나쁜 예 : 이거 왜 안되나요?, 오류나요 도와주세요 등 비슷한 궁금함을 갖고 계신 분들께 도움이 될 수 있어요! 코드의 이슈는 전체 프로젝트를 "링크 형태"로 올려주셔야 원인을 파악할 수 있습니다. 깃허브, 구글드라이브 등의 수단을 통해 링크 형태로 전달해주세요 직접 실행해보며 원인을 파악해야 하기 때문에 텍스트 형태로 붙여넣는건 삼가해주세요 🥲 답변이 도움이 되셨다면 답글 or 해결완료 버튼을 클릭해주세요 강의 내용에 궁금한 점이 있다면 몇 챕터의 몇 분 몇 초인지 알려주시면 더 좋아요 Date 객체와 날짜 안녕하세요. 정환님. Date 객체에 관련해서 질문이 있어 Q&A에 글을 남기게 되었습니다. Date 객체는 자바스크립트가 처음 만들어졌을 당시에, java의 util.date 를 참고해서 만들어졌기에 현재 대체제로 외부 라이브러리를 활용하거나 Intl api, Temporal(현재 stage 3 상태)가 많이 언급되고 있는 부분입니다. 추후에 temporal이 정식으로 도입되면 강의 내용을 변경하실 것인지 질문드립니다.
안녕하세요. 강의 너무 잘 보고 있습니다. 한 가지 궁금한 점이 있어서 QnA남깁니다. // __mocks__/zustand.js const { create: actualCreate } = await vi.importActual('zustand'); import { act } from '@testing-library/react' const storeResetFns = new Set(); export const create = createState => { const store = actualCreate(createState); const initialState = store.getState(); storeResetFns.add(()=>store.setState(initialState,true)); return store; } beforeEach(() => { act(() => storeResetFns.forEach(resetFn => resetFn())); }); 위의 __mocks__/zustand.js 에서 reset할 때 true를 사용하는 건 이해가 됩니다. 그런데 아래의 mockZustandStore 에서 replace:true 를 넣었는데 왜 넣어줬는지가 궁금합니다. const mockStore = (hook, state) => { const initStore = hook.getState(); hook.setState({ ...initStore, ...state }, true); }; export const mockUseUserStore = state => { mockStore(useUserStore, state); }; replace:true는 완전히 해당 store에 대한 상태,함수들을 교체 하는것으로 알고 있습니다. 넣어준 의도 또는 이유가 있을까요?? 안 넣어주면 생기는 문제들이 있었기 때문에 replace:true로 한건지 관례로 넣었던 건지
revalidatePath("/about", "page") 로 설정을 하고 테스트를 하다 보면 /about 페이지에서 재검증 버튼을 누르면 AboutLayout의 데이터 패칭 결과와 AboutPage의 데이터 패칭 결과가 함께 바뀌는 것과, /about/detail 페이지에서 재검증 버튼을 누르면 아무런 변화도 없는 이유가 revalidatePath의 첫 번째 인자로 설정된 "/about" 이 아닌 /about/detail 페이지에 접속해 있기 때문이라는 것까지는 이해했습니다. 하지만 detail 페이지에서 재검증을 누르고 about 페이지로 이동하면 즉시 AboutPage의 결과는 변하는데 AboutLayout의 결과는 변하지 않는데 이유가 뭔가요?
useEffect를 통해 setErros를 호출해서 errors 상태를 변경하고 있습니다. 상태를 변경하는 건 부수효과가 아니니까 useEffect에서 상태 업데이트는 잘못된 사용이 아닌가 해서요! 저것 때문에 렌더링이 두 번 되기도 하고, https://react.dev/learn/you-might-not-need-an-effect#updating-state-based-on-props-or-state 이 내용이랑 같은 내용인 것 같아서요!
혼자서도 해보고 '레이아웃 분리하기 - 풀이' 강의를 보고 똑같이 해도 (with-layout) 그룹에 생성한 Layout(MainLayout)은 아래와 같이 MainLayout 하위에 MainLayout이 또 있는 것처럼 뜨는데 이건 정상적인 건가요? (auth) 그룹에 생성한 Layout(AuthLayout)은 아래와 같이 AuthLayout이 하나만 있어서 어떤 게 정상인지, 원래 이런 건지 알고 싶습니다. 프로젝트 폴더 구조는 다음과 같습니다:
죄송합니다 또 궁금한게 생겨서 여쭈어봅니다 ai에게 물어봐도 항상 이게 진짜 맞는건지 의문이 생겨서 만약 프론트 쪽에서만 next js 에서 헤더랑 쿠키에 접근을 할 일이 그렇게 있을가 하는 의문이 생겨서 질문드립니다. 백엔드가 기본적인 확인을해서 처리를 하고 권한 이나 그런건 api호출을 하면 되지않을가라는 의문이 들어 질문 남깁니다
