[팀 서비스 클론 코딩] 엽토(김건엽) 미션 제출합니다. #35
Conversation
There was a problem hiding this comment.
안녕하세요 엽토~~ 엽토의 코드를 리뷰하게 되서 영광입니다. 👍
구현의 완성도가 정말 높군요! 야무지게 잘 보았습니다. 코드도 깔끔하게 잘 작성해주셔서 리뷰하는데 정말 편했습니다.
크게 수정할 부분이 없어보이네요! 코멘트 몇 개 남겼습니다. 확인 후 재요청 부탁드릴께요~
질문하신 내용에 대한 답변
SSG와 SSR
저도 이 부분이 가장 헷갈렸는데요. 제가 학습한 바로는 '사용자가 데이터를 요청(fetch)하는 시점'과 '빌드 타임'의 여부가 이 둘을 구분 짓는데 중요한 것 같아요.
공식문서(넥스트 12)에 의하면 SSG 는 빌드타임에 데이터 요청(fetch)을 모두 완료하여 정적 페이지로 사용하는 경우에 적합하다고 합니다. 대표적인 예시로 About 페이지 같은 것이 되겠죠. 즉, 빌드 타임에 데이터 fetch 가 모두 완료된다면 SSG로 만드는 것이 비용 측면에서 많은 이점을 얻을 수 있다고 생각해요.
그에 반해 SSR은 빌드 타임 이후에 사용자가 데이터를 요청하는 상황이 발생할 때 사용하는 것으로 알고 있습니다. 즉, 페이지를 빌드 한 이후에 사용자가 특정 버튼 등을 클릭하여 새로운 요청이 발생하고, 새로운 페이지를 빌드하는 경우 이를 SSR로 이해했습니다.
그런데 넥스트 13버전으로 넘어오면서 컴포넌트 개념이 강해졌더군요. 13버전의 공식문서에는 SSR, SSG, ISR 같은 개념 보단 서버 컴포넌트, 클라이언트 컴포넌트 같은 개념을 쓰는 것을 볼 수 있습니다.
서버 컴포넌트 파트를 보시면 SSG와 SSR, ISR에 대한 내용이 다소 함축되어 있는 것을 느낄 수 있는데, 결론부터 말씀드리면 Cache와 상당히 밀접한 관계가 있는 것 같더라구요.
기본적으로 정적 렌더링으로 동작하다가 Cache 되지 않는 요청이 발생하면 동적 렌더링으로 변경됨을 알 수 있습니다.
빌드 타임 이후에 사용자 요청이 발생해도 Cache를 무효화하지 않으면 페이지가 동작하지 않는 것을 확인해볼 수 있습니다. (참고 생활코딩 Next 13 Cache) 여기서 넥스트는 기본적으로 SSG 방식을 사용한다고 생각해요. Cache 무효화한 이후에서야 페이지가 갱신되는 것을 볼 수 있죠. (SSR)
캐시를 무효화할 수 있는 정책이 크게 세 가지가 있는 것 같더라구요. 일정 시간동안만 캐싱을 유지하는 방법이 있는데 이 방식이 우리가 보편적으로 알고 있는 ISR 방식으로 이해했습니다.
쓰다보니 매우 길어졌네요.. 저도 학습 중이라 잘못된 내용이 있을 수도 있습니다. 잘못된 내용이 있다면 알려주시면 감사드리겠습니다!!
이 부분에 대해서 잘 이해도 안 되고 의문이 많아져서 엽토에 질문에 많이 공감할 수 있었습니다. 👍👍
아무튼 미션 하시느라 고생많으셨습니다!
| -webkit-tap-highlight-color: transparent; | ||
| -webkit-text-size-adjust: 100%; | ||
| text-size-adjust: 100%; |
| up: 'M1 11L8 5L15 11', | ||
| down: 'M15 5L8 11L1 5', | ||
| left: 'M11 15L5 8L11 1', | ||
| right: 'M5 1L11 8L5 15', |
There was a problem hiding this comment.
svg path 태그 옵션을 직접 조정하는 것 같은데 방향 조정을 위한 것일까요?? 이런 것은 어디서 정보를 얻을 수 있나용?
| <div className={styles.introduce}> | ||
| <h2 className={styles.guideHeaderText}>하루스터디 학습 사이클</h2> | ||
| <p className={styles.guideDescriptionText}> | ||
| 한 사이클마다 <span>목표 설정 단계</span>, <span>학습 단계</span>,{" "} |
There was a problem hiding this comment.
띄어쓰기 때문에 사용한건데요, 린트가 알아서 저렇게 바꿔버리더라구요!
| onMouseEnter={() => setIsHoverIcon(true)} | ||
| onMouseLeave={() => setIsHoverIcon(false)} |
| color: #38848a; | ||
| } | ||
|
|
||
| @media screen and (max-width: 768px) { |
There was a problem hiding this comment.
모바일 사이즈를 768px 부터 지정하신 것 같아요. 768px로 기준을 정한 이유가 있으실까요?
저도 프로젝트에서 반응형 로직을 리팩토링하는 과정인데 media 쿼리가 파편화 되어있어서 관리하기가 어렵더라구요. 엽토는 반응형 로직을 어떻게 관리하시나요??
There was a problem hiding this comment.
보통 일반적인 태블릿 사이즈 기준이 768px부터더라구요! 그래서 768px 기준을 잡았습니다!
저희는 페이지 성격에 따라 페이지 별 공통 Layout 컴포넌트들이 있어요. 최상단의 Layout 컴포넌트에서 미디어쿼리를 적용시켜 반응형이 적용될 수 있도록 초반에 설계를 했었어요! 하지만 앱이 커질수록 어쩔 수 없이 하위 몇몇 컴포넌트들에 직접 미디어쿼리를 적용시켜줄 수 밖에 없더라구요! 파편화가 되어있긴 하지만 막 그렇게 복잡하다고 생각하진 않아서 따로 분리하거나 관리해주지 않았습니다ㅎㅎ
|
세인의 생각을 자세하게 말씀해주셔서 감사합니다! 코멘트에 대해 답변남겼으니까 확인부탁드릴게요! |
반갑습니다 세인~
세인이 리뷰해준다는 생각에 기분이 좋네요 :)
설명은 아래에 하도록 할게요!
🎨 1단계 - 팀 서비스의 일부 페이지 클론 코딩
🚀 구현한 페이지의 주소와 방식
✅ 체크리스트
선택한 렌더링 방식의 이유
저는 클론 코딩할 페이지를 랜딩페이지(Home)을 선택했어요. 아무래도 가장 유입이 많은 페이지이고, 저희 서비스에서 로딩하는데 가장 오래걸리는 페이지이기도해서 서버에서 만들어진 html을 넘겨주면 얼마나 효과적일지 궁금했기 때문이에요!
렌더링 방식 선택에 대해 말씀드리자면 저희 랜딩 페이지에선 서버 API를 호출하여 데이터를 띄워주는 로직이 없기때문에 선택의 여지가 SSG 뿐이었습니다ㅠ 코드를 보면 아시겠지만, fetch하는 로직이 없어요..! 외부 의존 없이 내부 데이터만을 사용해서 정적인 페이지를 만들어줘요..
기존 저희 하루스터디에 네트워크탭을 확인해보시면 랜딩 페이지에서 빈 html을 주지만 Next로 마이그레이션한 랜딩 페이지에선 컨텐츠가 다 채워진 html을 받아오는걸 확인하실 수 있으실거에요!
저는 SSR SSG 이 두개가 참 헷갈리더라구요. 저는 둘 다 서버단에서 렌더링하니까 SSG도
서버 사이드 렌더링방식이지 않나라는 생각이거든요. 어디서 참고한 글에는 SSG는 SSR의 하위개념이다 이런 말도 있더라구요? 크루들과도 대화를 많이 나눠봤는데도 두 개념의 의미가 한줄로 정리가 되지 않네요ㅠ 세인은 어떻게 생각하시는지 궁금합니다!코드 재사용
하루스터디에선 CSS In JS 방식인 styled-components를 사용하는데 Next 공식문서를 보니 CSS In JS는
요런 내용이 있더라구요! Next13 핵심이 서버 컴포넌트 컨셉인걸로 아는데, CSS In JS는 서버 컴포넌트말고 클라이언트 컴포넌트에서 사용할 수 있다해서 CSS Module 방식으로 마이그레이션 했어요~ 문법만 바뀐거고 스타일링이나 컴포넌트 틀은 Button 및 Typography 컴포넌트 제외하고 기존 서비스와 동일합니다! Button과 Typography는 랜딩페이지에서 필요한 정도로만 구현했습니다!
원래 시작하기 누르면 모달이 뜨면서 로그인 버튼이 나타는데, 모달이 context와 portal로 구현되어있어서 Next로 마이그레이션 하려니까 생각보다 엄청 복잡하더라구요.. 시간 관계상 일단은 안해놨습니당 ㅎㅎ.. 참고하세용
이상입니다~ 리뷰 잘 부탁드려용~!