안녕하세요, 쉬운 강의 덕분에 gsap 을 쉽게 접하고 사용할 수 있어서 감사합니다. 근데 해당 부분 구현중에 범샘께서 작성하신 코드(ScrollTrigger-finished)에서 확인해보면 1) section3 도달 후, section2로 스크롤을 올리는 경우 2) section4 도달 후, section3에서 다시 section4 로 스크롤을 내리는 경우 해당 2가지 경우에서 section03을 기준으로 스크롤이 위아래로 작동을 잘 하지 않습니다. if(currentPageIndex === 3) return; 때문인 것 같은데, 스크롤을 자유롭게 올렸다 내렸다 하면서 페이지를 확인할 수 있도록 하려고 하는데 잘 안되네요. 코드를 어떤 방식으로 수정해야할지 질문 남깁니다. 감사합니다.
안녕하세요! NextJS 에 대한 Flow 설명중 질문이 있습니다 9:01 Timeline 유저의 접속요청시 해당 페이지에 대한 내용만 랜더링하여 HTML 을 반환하는 걸까요? 그게 아니고 설명하신 모든 컴포넌트에 대한 렌더링이 이루어지는 것이라면 CSR 방식과 마찬가지로 HTML 반환이 늦어지지 않나 싶습니다 또한 사전 렌더링이 NextJS 서버가 부팅시 이루어지는 행위인지 궁금합니다! (서버 부팅시 랜더링된 HTML 이 생성되는지)
▲ Next.js 14.2.8 - Local: http://localhost:3000 - Environments: .env ✓ Starting... ✓ Ready in 4.2s ○ Compiling / ... ✓ Compiled / in 3.5s (1022 modules) GET / 200 in 4384ms GET / 200 in 81ms ✓ Compiled /api/auth/[...nextauth] in 364ms (493 modules) GET /api/auth/session 200 in 2386ms ○ Compiling /login ... ✓ Compiled /login in 1020ms (1035 modules) GET /api/auth/session 200 in 1561ms GET /login?_rsc=1pqm1 200 in 126ms ○ Compiling /(.)i/flow/login ... ✓ Compiled /(.)i/flow/login in 731ms (1050 modules) GET /api/auth/providers 200 in 44ms GET /api/auth/csrf 200 in 19ms [auth][error] CallbackRouteError: Read more at https://errors.authjs.dev#callbackrouteerror [auth][cause]: TypeError: Failed to parse URL from undefined/api/login at node:internal/deps/undici/undici:13178:13 [auth][details]: { "code": "ERR_INVALID_URL", "input": "undefined/api/login", "provider": "credentials" } POST /api/auth/callback/credentials? 200 in 40ms GET /api/auth/session 200 in 26ms 윈도우 인데 memurai설치가 도저히 안 되어서 그냥 redis 설치했습니다. 백엔드 코드 실행시키면 redis connected라고도 뜨고, service에도 실행중도 뜨고, hello world도 잘 뜹니다. REDIS_URL=redis://127.0.0.1:6379 //백엔드 env NEXT_PUBLIC_BASE_URL=http://localhost:3000 //z-com 에 있는 .env 이거로도 고쳐봤습니다. localhost:3000/login 여기로 넘어는 가는데 로그인이 안 됩니다. 깃허브에서 코드 잘 가져왔고, 회원가입도 잘 되는데 로그인만 안 됩니다. 뭐가 문제일까요 ㅠㅠ
it('최소 가격 또는 최대 가격을 수정하면 setMinPrice과 setMaxPrice 액션이 호출된다.', async () => { const { user } = await render(<ProductFilter />); const minPriceInput = screen.getByPlaceholderText('최소 금액'); const maxPriceInput = screen.getByPlaceholderText('최대 금액'); await user.type(minPriceInput, '10'); await user.type(maxPriceInput, '10000'); expect(setMinPriceFn).toHaveBeenCalledWith('10'); expect(setMaxPriceFn).toHaveBeenCalledWith('10000'); }); 전 이런식으로 작성했습니다. 단위 테스트에서 알려주신 AAA패턴을 해당 통합테스트에서도 적용하면 깔끔할 것 같아서 이렇게 작성했어요. 어차피 검증할건 setMaxPriceFn & setMinPriceFn이 호출됐는지 여부라 최소금액 및 최대금액 인풋을 연속적으로 조작하게 했습니다. 혹시 이렇게 하면 문제가 있는지 궁금합니다
기초부터 배우는 Next YTMusic 클론 코딩 (with next.js 14, UI 마스터)
안녕하세요. 우선 소개부터 드리자면 저는 FE 개발자나 그쪽을 지망하는 것은 아니고 백엔드를 업으로 하고 있고 집에서 홈서버에 제 개인 서비스를 배포할 목적으로 해당 강의를 수강하게 되었습니다. 사실 제가 프론트의 세계는 잘 몰라서 질문 드립니다. 혹시 페이지 로드 속도 & 검색 엔진 노출도가 배포 플랫폼에 영향을 받을까요? 다른 말로는, versel 을 통해 프론트를 배포하는 것이 배포가 쉬운 것 이외에 서비스의 퀄리티에도 도움을 주는 장점이 있을까요 ?
[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
현재 듣고 있는 강의 부분은 Guard chapter에서 basic, bearer guard를 적용하는 부분입니다. @Injectable() export class BearerTokenGuard implements CanActivate { constructor( private readonly authService: AuthService, private readonly usersService: UsersService, ) {} async canActivate(context: ExecutionContext): Promise<boolean> { const req = context.switchToHttp().getRequest(); const rawToken = req.headers['authorization']; if (!rawToken) { throw new UnauthorizedException('토큰이 없음'); } const token = this.authService.extractTokenFromHeader(rawToken, true); const result = await this.authService.verifyToken(token); // payload 반환 /** * req 객체에 넣을 정보 * 1) 사용자 정보 - user 객체 자체 * 2) token - token * 3) tokenType - access | refresh */ const user = await this.usersService.getUserByEmail(result.email); req.user = user; req.token = token; req.tokenType = result.type; return true; } } 제 개인적인 생각으로는 적어도 제목에 적힌 두 엔드포인트에 대해서는 현재의 BearerTokenGuard를 적용하는 것이 굳이 라는 생각이 듭니다. refreshToken을 이용하여 새로운 토큰을 발급받는 역할을 하는 두 엔드포인트에 대해 다른 줄은 다 문제가 크게 없다고 생각하지만 req.user = user;로 굳이 요청에 user 객체를 붙이는 것은 굳이라는 생각이 듭니다. 제 낮은 식견으로는 위 두 엔드포인트에 대한 guard는 또 따로 만들어야 한다고 생각이 드는데 강사님 생각이 궁금합니다.
2.5) 원시타입 VS 객체타입 약 08:50. 안녕하세요, 강사님의 강의를 만족하며 잘 듣고있는 수강생입니다. 해당부분에 다소 오해의 소지가 될 내용으로 추가 강의 업데이트시 반영되었으면 하는부분이 있어서 올려봅니다. '객체의 참조값을 복사함' 이라는 문장은 맞다고 볼 수 있지만, 이를 얕은 복사라 부르기엔 오해의 소지가 많을것으로 보입니다. o2는 o1의 포인터값을 그대로 똑같이 가지고 있을 뿐, o2가 가리키는 값이 o1과 동일하게 '새로운 값이 만들어지지 않았기 때문' 입니다. 또한, '새로운 객체를 생성하면서 프로퍼티만 따로 복사함'이라는 문장또한 맞다고 볼 수 있지만, 이를 깊은 복사라 부르기엔 오해의 소지가 역시 많을것으로 보입니다. 실제로 공식문서에서도 이를 논하기에는 쓸모없다고 얘기하고있지만, 그러면서 Shallow copy에 대해서 아래와 같이 강조하고있습니다. For shallow copies, only the top-level properties are copied, not the values of nested objects. 때문에, 추가적인 nested objects에 문제가 따르며 실제로 이때문에 이를 얕은복사라고 많은 개발자들이 소통하고 있는것으로 알고있습니다. 특히, '원본 객체가 수정될 수 없어 안전함' 까지 있으니, 더욱더 top-level의 중요성이 강조되지 않는 것으로 보여 모호한것으로 보입니다. 평소 강사님의 강의, 강연등을 즐겨듣고 있는 수강생으로써 약간의 다소 오해의 소지가 있는부분을 언급해 볼 뿐이오니 너그러이 내용을 참조해주시면 감사하겠습니다. 항상 감사합니다. 이상입니다.
안녕하세요, 선생님. 강의를 모두 듣고 개인 프로젝트에 적용해보고 있는 중에 궁금한 점이 생겨 질문 남깁니다. 이번 강의에 나온 cypress cloud를 사용해서 테스트 자동화를 해보았는데 문득 cypress가 아니라 cypress cloud를 사용해서 테스트 자동화를 하는 이유가 무엇인지 궁금하더라고요. https://docs.cypress.io/guides/continuous-integration/github-actions 위 문서를 찾아보니 cypress cloud는 테스트를 병렬로 진행해서 속도가 더 빠르다고 하는데 병렬 테스트를 위해 cypress cloud를 사용하는 것인지 궁금합니다. 아니면 뭔가 다른 이유가 있을까요?
안녕하세요? 바탕화면에 codecamp-frontend 라는 폴더를 만들고, 그 아래에 class 라는 폴더를 만들어서 리액트 첫 보일러플레이트를 만들었습니다. section01 폴더도 만들고, 차근차근 하고 있습니다. 그런데, 깃허브로 바탕화면에 있는 codecamp-frontend 라는 폴더를 관리해주고 싶은데, 배운 대로 git init 을 하고 git add . 을 하니, 터미널에서, 이 폴더의 하위에 있는 class 라는 폴더가 서브모듈이 된다고 경고가 뜹니다. 그래서 검색을 해서 어찌어찌 되돌리고, 하위에 있는 class 폴더만 깃허브 리포지토리로서 관리하게 되었습니다. 그런데 class라는 이름의 리포지토리가 있는 것이 마음에 안 들고, 몇 가지 질문이 생겼습니다. 리액트 앱은 그 자체를 단독으로, 하나의 리포지토리로서 관리해주는 것이 맞나요? class 라는 이름의 리포지토리가 있는 것이 알아보기 어렵고 중복이 쉬워 이름을 바꾸고 싶습니다. 바꿔주어도 상관없을까요? 깃이 꼬이지 않을까요? 깃과 깃허브로 리액트 앱들을 하나의 폴더(리포지토리(저장소))로 모아서 관리하려면 어떻게 관리해 주어야 하는 건지 궁금합니다. 감사합니다.
강의내용이 24년 현재 9월 듣고 있는데 강의 내용과 내려받는 리엑트 네이티브 파일구조가 달라서 너무 어렵습니다. 현재 강의 맞는 구버전으로 하면 expo app 버전이 구버전과 맞지 않는다고 하거나 강의 보면서 하기도 벅찬데 각종 버전에 따른 오류가 너무 많이 나오니 해결하면서 강의 듣기에 너무 힘듭니다. 뭔가 방법이 없을까요? 제가 너무 배우고 싶었던 리엑트 네이티브 강의인데 초반에 오류 수정하다 끝나고 이러니 의지가 꺽여버립니다.
실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트
unit-test-example에서 테스트를 실행하니 테스트코드 통과 여부에 관계없이 Test result not found만 뜨며 실패합니다. 이유를 모르겠어요ㅠㅠ Test result not found. If you set `vitest.commandLine` please check: Did you set `vitest.commandLine` to `run` mode? (This extension requires `watch` mode to get the results from Vitest api) Does it have the ability to append extra arguments? (For example it should be `yarn test --` rather than `yarn test`) Are there tests with the same name? Can you run vitest successfully on this file? Does it need custom option to run?
안녕하세요 강의를 듣고 next-auth를 활용하여 개발 중에 궁금한 점이 생겨 질문 드립니다. 프로젝트에서 일반 로그인과 소셜 로그인을 모두 사용하고 있어 next-auth의 signin callback에서 로그인일 경우 자체 서버에 요청하여 accessToken과 refreshToken을 발급 받고 jwt callback에서 엑세스 토큰의 만료 시간을 체크하여 만료 시에 재발급 요청이 되도록 구현하고 있습니다. 이렇게 구현했을 경우 간헐적으로 서버 시간과의 타이밍 이슈 때문인지 api 요청 시에 401 토큰 만료 에러가 발생하는 순간이 존재합니다. 따라서 401 상태코드일 경우에 refreshToken 토큰 재발급 요청을 하려고 하는데 refreshToken이 현재 next-auth에서 jwt 콜백에서 리턴되어 jwt토큰으로 생성되어 있습니다. 이 401일 경우 재발급 요청 처리를 클라이언트 단에서 할 경우 refreshToken이 노출되어 보안상 이슈가 있을 것으로 예상이 되는데 서버단에서 처리를 하려면 next에서 어디서 처리를 하면 좋을 지 문의드립니다. async signIn({ account, user, credentials }) { const cookieStore = cookies(); const authorizationParams = JSON.parse( cookieStore.get("authorization-params")?.value ?? "" ); const action = authorizationParams.action; user.platform = authorizationParams.platform; if (!account?.provider || !sns_type_map[account.provider]) { throw new Error("Unsupported provider"); } user.snsType = sns_type_map[account.provider]; if (action === auth_action_type.signin) { return handleSignIn(user); // getAccessToken } if (action === auth_action_type.signup) { return handleSignUp(); } return false; }, async jwt({ token, account, user }) { // Initial sign in if (account && user) { return { ...token, ...user, accessToken: user.refreshToken, expiresAt: new Date( Date.now() + (user?.expiresIn ?? 0) ).toISOString(), refreshToken: "refreshtoken", }; } // Return previous token if the access token has not expired yet if (new Date() < new Date(token.expiresAt as string)) { console.log("@@@@@@valid"); return token; } else { // Access token has expired, try to update it console.log("@@@@@@expired"); const cookieStore = cookies(); const authorizationParams = JSON.parse( cookieStore.get("authorization-params")?.value ?? "" ); const body = { .... }; const tokenData = await authApi.reissueAccessToken(body); // reissue token return { ...token, ...user, accessToken: tokenData.accessToken, expiresAt: new Date( Date.now() + (tokenData.expiresIn ?? 0) ).toISOString(), refreshToken: tokenData.refreshToken, }; } }, 미들웨어에서 401 상태 코드 처리하는 것도 알아보았으나 일반적인 방식인지 궁금합니다. 미들웨어에서 401일때 재발급 요청 시 새로운 엑세스 토큰으로 재요청이 정상적으로 되는 것은 확인했으나 다시 next-auth의 jwt토큰에 재발급된 값을 세팅해줘야 하는데 어떻게 해야할지도 궁금합니다. import { NextResponse } from 'next/server'; import { getToken } from 'next-auth/jwt'; export async function middleware(request) { const token = await getToken({ req: request, secret: process.env.AUTH_SECRET }); if (request.nextUrl.pathname.startsWith('/gateway')) { const accessToken = token?.accessToken; const headers = new Headers(request.headers); if (response.status === 401) { const refreshToken = token?.refreshToken; const refreshResponse = await fetch("/reissueToken") const refreshData = await refreshResponse.json(); if (refreshResponse.ok) { const newAccessToken = refreshData.accessToken; headers.set('Authorization', `Bearer ${newAccessToken}`); const newResponse = NextResponse.next({ request: { headers: request.headers, }, }); } // 토큰 재발급 실패 시 처리 return NextResponse.redirect('/login'); } return NextResponse.next(response); } return NextResponse.next(); }
