제안한 것>

회원

• OAuth로 링크 가능 (google/kakao/github)
  • 회원가입시 아래 정보 입력
    • 닉네임
    • 아이디(id
    • 비밀번호
  • 닉네임과 아이디는 사용자가 입력을 마쳤다고 판단할 때 서버를 통해 체크한다.
• 프로필
  • 비번 바꾸기
  • 프로필 사진 바꾸기 (로컬 파일로만)
  • 소셜 계정 연동 추가
  • 탈퇴하기

문제

• 문제 등록/수정/삭제
  • 제목
  • 문제등급
  • 시간 제한/ 메모리 제한
  • 문제 설명(전체적인 거)
  • 입력 설명
  • 출력 설명
  • 예제 입력/출력(테스트케이스 여러개일 수 있으므로 배열로)
  • tag(어떤 문제 유형인지)
  • 실제 입력 데이터 및 출력 데이터(테스트 케이스)
  • 제출 횟수/정답 횟수/맞힌 사람/정답률
• 문제 채점 ( c/c++/python2/python3/java)
  • 실행하기 버튼 → 단순 코드 실행해서 실행 결과 보여주는거
    • Judger의 실행 결과 + 채점 결과를 응답해줌 (예제 데이터로만 채점)
  • 제출하기 → 진짜로 제출
    • Judger의 채점 결과만 응답 (실제 채점 데이터로 채점)

채점 현황

• 본인꺼는 항상 뜨고 타인꺼는 채점결과 페이지에서만 표기
  • STOMP subscribe 사용

제출 이력

• 저장 데이터
  • 제출 번호
  • 시도 수
  • 언어
  • 제출 시간
  • 채점 결과 (메모리, 시간, 결과)
  • 코드 길이
• 모든 채점 제출 이력 저장
• 이력과 비교해서 같은 코드일 경우 채점 X

맞힌 사람

• 제출 이력을 소팅
  • 메모리 > 시간 > 코드 길이

랭킹

• 데이터
  • 맞은 문제
  • 제출
  • 정답 비율

페이지 정리

설계 하기 편하니까! 계속 디자인 고민을 안해도 되니까!

여러 프로젝트를 진행하면서 디자인이 없는 경우가 많았다. 개발공부를 시작한지 얼마안돼서 초기에는 와이어프레임 정도만 만들고 '스테이트는 필요해 보일때 마다 알아서 만들어서 관리하자^-^'라고 생각하고 개발했었는데, 늘 커다란 에러가 생겼고 그 에러를 해결하는데 나머지 부분을 개발하는 것보다 더 많은 시간을 투자했었다. ** 설계를 하지 않거나 꼼꼼하지 않은 설계를 하면, 결국 상태가 꼬여버리고 그 문제를 해결하기 위해 많은 시간을 들여야할 뿐만 아니라 코드가 더러워지는 경우가 많았다.** 설계 부재의 참혹함을 느낀 이후로 꼭 스테이트 설계/ 코드 구조 설계/ 여러 컨벤션 등을 먼저 정하고 개발에 들어가는 편인데, 이 때 디자인이 구체화되어 있지 않으면 컴포넌트를 어떻게 쪼갤지 상상이 잘 안돼서 힘들때가 많았다. 그래서 일찌감치 UI를 만들어 설계하기 쉽게 하려고 했다.

설계할 때 고려할 것

• 주로 통신으로 받아온 데이터를 어떻게 관리할 것이며 오류 처리는 어떻게 할 것인가를 생각해서 설계
  • 어떤 식으로 컴포넌트를 쪼갤지
  • 스테이트는 어디서 관리하고 어떻게 내려줄
  • 전역 스테이트가 어울릴지 그냥 지역적으로 스테이트를 사용할지
  • 애초에 스테이트가 필요한 부분은 맞는지 생각!

피그마를 사용해보자

• AdobeXD를 사용한 경험이 있었는데 지금은 유료화가 돼버려서😭 피그마를 사용했다.
• 일단 깔끔하게 보이게만 해뒀고, 어떤 컴포넌트가 어떤 식으로 들어갈지만 정리해두었다.=

왜만드니?

대학교 재학시절 나는 SW운영보조원 활동을 2년간 했다. 주로 어떤걸 했었냐면..

• QnA 답변 활동 : 프로그래밍 과목 QnA게시판에 대한 답 달아주기(과제하다가 막힌 부분이 있으면 힌트를 주는 방식으로 진행)
• 오픈소스 프로그램 커스텀 : Indico 한글화 및 필요한 기능만 남기기, 디자인 커스텀 여담) 웹 개발 자체도 처음이었는데 flask가 너무 생소하고, 그 당시 나에겐 너무 큰 규모의 프로그램이었던지라 코드를 읽는데 정말 많이 애를 썼다. 1년 동안 얼렁뚱땅 수정을 하긴 했었는데 2년이 지난 지금에서야 어떤 구조로 돼있었는지 어렴풋이 이해가 가는 것 같다.
• 도커 튜토리얼 작성 : 도커 사용법 및 간단한 예제를 만들어 ppt로 제작했다.
• Online-Judger 개발 : angular, express.js, kafka, mongodb를 이용해 개발을 하려고 했고, 도커 + 젠킨스를 이용해 학교 서버에서 배포하려고 했다. 하지만 웹개발 초보자였던 나에게는 이 모든걸 하기 너무 벅찼다.. 결국 이론만 공부하다가 1년이 다 가버렸고 실질적인 개발에 많은 도움이 되진 못했다. 나는 도커에서 카프카 컨슈머가 메세지를 분배해서 가져가지 않고, 한 컨슈머가 모든 메시지를 가져오는 이슈를 해결했었다.
• 대신 거기서 배운 것들을 ( docker, express, RESTAPI, kafka )를 졸업작품에 적용해보았다.
• 온라인 져저를 직접 구현해보고 배포한 경험이 생긴다면 정말 멋있을 거라고 생각했는데, 내 기여도는 상당히 낮아서 아쉬웠다😭. 언젠가 꼭 내손으로 만들어보고 싶었고, 웹 개발에 대한 지식이 조금 생겼다고 생각이 들어 만들어보기로 했다!

어떤 기술들을 사용할까?

• 우선 내가 하고 싶어서 해보는 프로젝트인 만큼 내가 쓰고 싶었던 기술들도 마음껏 써보기로 했다!(이 프로젝트에 딱 맞는 기술이 아니라고 할지라도,, graphql같이 너무 방향성이 다르다~싶은 것만 아니면 써보기로 했다. )

  그동안 배우고 써본 것들

• 리액트 : 애증하는 리액트..
• 약간의 최적화(LazyLoading, 렌더링 최적화, 코드 스플리팅)
• 리덕스
• 리덕스 툴킷
• 타입스크립트

공부했지만 써보지 못한 것들

• Next.js : 쓸까말까 정말 고민을 많이 했다. 온라인 져저 특성상 스테이트의 변화가 매우 잦기 때문에 Next.js를 쓰는 의미가 있을까?싶었는데 문제를 보여주는 페이지는 정적으로 만들어줘도 나쁘지 않다고 생각해서 Next.js를 써보기로 했다.
• 리덕스 사가 or redux toolkit의 createAsyncThunk: 늘 예제에서만 실행해보고 사용해봤던, 그 리덕스 사가! 내가 푼 문제의 채점 현황을 리덕스로 관리해서 알림으로 띄워주면 좋을 것 같은데, 채점에 걸리는 시간은 들쭉날쭉하니 비동기로 처리해야한다. => 이거 완전 리덕스 사가쓰기 좋은 이슈아닌가! 그래서 망설임 없이 리덕스 사가를 써보기로 했다.
• OAuth
• Jest, React Testing Library, ... (테스팅)

모르지만 써볼 것

• Github Action(CI/CD)
• STOMP

• 기존 서비스 : https://github.com/YOONLEEVERSE/onlinecourse-front

• 온라인 강의를 등록하고 관리할 수 있고, 수강이 가능한 서비스이다. 유튜브에서 유용한 강의를 모아서 강의 리스트로 만들어 한 페이지에서 쉽게 볼 목적으로도 사용할 수 있을 것 같았다.

🤔 왜 다시 만들게 되었나?

• 취준생이라는 생각을 하니 마음이 조급해지기만 했고 단기간에 많은 서비스를 구현해야 한다고 생각했다. 그래서 graphql 이나 react 구조를 처음부터 꼼꼼하게 설계하지 못했고 후반부로 갈수록 코드는 더러워져만 갔다. 프로젝트를 진행하면서 내가 옳게 구현하고 있는건가,.? 나는 왜이렇게 못하지..?라는 생각에 좀 슬럼프를 겪으면서 해당 서비스의 구현이 많이 딜레이 됐다.
  • 겨우겨우 필수 기능 구현이 완료됐지만 구조며 코드며 하나도 마음에 드는 게 없었다. 좀 더 깔끔한 설계와 코드가 필요하다고 생각한 나는 원티드 프리온보딩 코스를 듣게 되었다. 원티드 프리온보딩 프론트엔드 코스를 진행 하면서 내 코드의 문제점을 많이 파악하게 됐는데 기존 프로젝트를 보완해보고 싶다는 생각이 들었다. 그래서 제일 처음 재구축 할 프로젝트로 이 온라인 코스 서비스를 선택하게 되었다.
  • 제일 최근에 만든 서비스라 어떤 의도로 만들었는지, 어떻게 생각하면서 그 부분을 구현했는지 기억이 제일 잘 나서 잘못 생각했던 부분을 고치기 가장 쉬울 것 같았다. 그리고 구조 분리를 시도해보기도 했던 때라, 그나마 폴더 구조가 정리 돼있어서 과거의 코드와 현재의 코드를 비교해보기 좋을 것 같았다.

📖새로 만들 때 원칙

1. 단일 컴포넌트에서는 되도록 하나의 일을 하도록 하자
2. common한 함수/컴포넌트와 한 컴포넌트에 종속돼있는 함수/컴포넌트를 잘 구분지어 정리하도록 하자
3. useRef를 써서 리렌더링을 좀 줄일 수 있도록 해보자
4. 혼자 하는 프로젝트지만, commit convention, code convention을 잘 지키면서 구현하자
5. 무작정 구현하지 말자. 충분히 생각을 해보고 설계를 마친 후에 구현하자! 설계가 훨씬 중요하다. UX도 충분히 고려한 설계일 것
6. Theme Provider를 이용해 theme을 관리하도록 하자
7. 클린한 코드를 짤 수 있도록 늘 노력하자
8. 리팩토링은 필수!
9. UI 라이브러리에 의존하지 말 것. 웬만하면 내가 다 구현하자
10. 폴더 구조를 깔끔하게 가져가자
11. 통신 모듈은 항상 그냥 쓰지 않는다. Wrapper로 한 번 묶어줄 것(에러 핸들링을 하기 위함)
12. 테스트 코드를 작성해보자
13. 최적화를 해보자(useMemo, useCallback, Debounce, Throttle)

Syntax VS Semantic

• syntax : 문법적인 것 => 보통 디버거로 잡기 쉬움

• semantic : 의미적인 것 => 로직이나 프로그램의 흐름 등. 논리의 오류 때문에 발생하는 문제이기 때문에 디버거로 잡기 쉽지 않음

  JavaScript와 ECMAScript

  ECMAScript

• ECMAScript === ECMA-262(자바스크립트의 표준 사양).

• 프로그래밍 언어의 값, 타입,객체와 프로퍼티, 함수 등에 적용된 규칙이라고 생각하면 된다.

  JavaScript

• ECMAScript(기본 뼈대) + Web API(브라우저 지원, DOM,BOM, Canvas, XMLHttpRequest...)

• 특징

  • 기본문법은 c, java와 유사

  • 프로토타입 기반 상속

  • 일급 함수 개념 차용(일반 변수값처럼 사용할 수 있는 함수, 즉 return값으로도 함수를 줄 수 있고 parameter로도 함수 넘겨주기 가능)

  • 인터프리터 언어

  • 멀티 패러다임 프로그래밍 언어. 명령형 + 함수형 + 프로토타입 기반 객체지향 프로그래밍

    프로그래밍 패러다임

    명령형 프로그래밍 = 무엇을 어떻게 할 것인가. '어떻게'할 지를 중심으로 코드로 만들어주면 됨 함수형 프로그래밍 = '어떻게'를 안 보이게 한다. 작은 문제를 해결하기 위한 함수를 만들어 그 함수를 사용하는 방식.

• ES6를 지원하지 않는 브라우저가 있기 때문에 ES6이상의 최신 문법을 적용할 경우 babel같은 트랜스파일러로 ES5이하의 사양으로 다운그레이드해줘야한다.(어차피 다 같은 코든데 최신 문법을 적용했냐 안했냐의 차이다)

JavaScript개발 환경

1. 브라우저

• 원래는 브라우저환경에서 실행되도록 만들어진 언어. 브라우저는 자바스크립트 엔진을 내장하고 있다.
• 클라이언트 사이드 WebAPI 지원(DOM,BOM,Canvas, XMLHttpRequest, fetch, requestAnimationFrame, SVG, Web Storage, Web Component, Web Worker)

  2. Node.js

• 브라우저 외의 환경에서도 JS가 실행될 수 있게 해준다. Node.js도 자바스크립트 엔진을 내장한다.
• 파일시스템을 기본 제공

주의! 브라우저와 Node.js는 용도가 다르다.

브라우저 : JS를 실행해 웹페이지를 브라우저에 렌더링하는 게 주목적 Node.js : 브라우저 외부에서 자바스크립트를 실행하는 게 주목적 각자 추가로 제공하는 API가 다르다.

01. 선발과제 리팩토링

구조

• styled-components 를 따로 분리 했다면 파일명이나 폴더 구조로 알아 볼수 있게 하면 좋겠습니다.(ex style.Input.js 등)

컨벤션

• 축약어를 사용하지 않고 검색가능한 변수를 사용하면 좋겠습니다.

// 이렇게 처리 하신 부분 넘 좋네요. 
// 이렇게 하면 useEffect가 실행 될 때만 함수가 재선언 되기 때문에 
// 외부에서 사용하지 않는 함수라면 넘 효율적이죠!
useEffect(() => {
    async function fetchData() {
      const result = await getFeed();
      setFeeds(result);
      setIsLoading(false);
    }
    fetchData();
  }, []);

    <>
      <GNB />
      {isLoading ? (
        <Loader>loading...</Loader>
      ) : (
        <FeedContainer feeds={feeds} isLoading={isLoading} />
      )}
    </>

        // 요런 방법도 상황에 따라 고려해보시면 좋습니다. 길이가 길면 길수록 삼항연산자는 가독성이 떨어져요!
        // 물론 지금정도 길이에선 삼항연산자가 더 좋을 수 있습니다! 참고용!
        <>
      <GNB />
      {isLoading && (<Loader>loading...</Loader>)}  
      {!isLoading && (
        <FeedContainer feeds={feeds} isLoading={isLoading} />
      )}
    </>

로직

• if문이 반복되면 함수 분리를 고민해봅시다.
• form 이벤트를 사용하면 keydown을 따로 처리 하지 않아도 됩니다.

02. 영화 정보 사이트

구조

• router는 유일하지 않을 확률이 높습니다. 지금은 괜찮지만 추후에 라우터가 추가 된다면 폴더로 따로 분리 해주시는것도 좋은 방법입니다.
• globalStyle과 theme을 styles를 만들어 모아주시면 유지 보수할때 더 편할 것 같습니다.
• recoil파일은 store라는 폴더를 따로 두고 관리하면 좋을 것 같습니다.

컨벤션

• 컨벤션은 잘 맞춰진 느낌이 듭니다!

로직

• Modal의 Overlay가 굳이 필요한지에 대해 의문이 있습니다. prop으로 받은걸 그대로 재사용할 뿐이라면 Styled-components에 바로 넘겨주어도 괜찮을 것 같습니다.
• 이전 리팩토링에서처럼 검색창 input을 ref로 활용해보시면 좋을 것 같습니다. 검색 버튼을 두면 ref에서 검색 버튼을 누를 때 current.value를 가져오는 방법으로 랜더링 최적화를 시킬 수 있을 것 같습니다.

// find를 사용하셔도 좋을 것 같습니다.
const handleCardClick = (movieId) => {
    const [movie] = movies.filter((movie) => movie.id === movieId);
    setSelectedMovie(movie);
    openModal();
  };

참고

Array.prototype.find() - JavaScript | MDN

02. 영화 정보 사이트 part 2

구조

• database를 src 외부로 옮기는 것도 고려해보시면 좋겠습니다. (제가 src에 넣어두어서….;;)
• pages 내부에 해당 페이지에서 사용하는 컴포넌트를 넣지 않고 components에 page에서 쓰이는 컴포넌트를 따로 모아두는 것도 좋아보입니다.
• globalStyle은 따로 styles 폴더로 관리해주시면 좋을 것 같습니다.

컨벤션

• 대체적으로 잘 정리 된 것 같습니다! 컴포넌트 내부의 변수나 함수 등의 순서를 일관성있게 관리해보시는 것도 추천드려요!

로직

• custom hook을 더욱 적극적으로 사용해보시는 것도 좋겠습니다! 사실 필요 없는 부분에 적용할 필요는 없지만 연습하신다 생각하고 후에 재사용이 가능하다고 느껴지는 부분이 있다면 적용 해보세요.

폴더 구조 고민

components/ -common한 컴포넌트 모아두는 곳 store/ - redux, recoil등 상태관리 관련 모아두기 hooks/ - 공통 hook 작성 pages/ - page 모아두는 곳 services/ - 아직도 역할 잘 모르겠움. styles/ - 공통스타일 관련 utils/ - 공통적으로 쓸 수 있는 것들 모아둠 ├─ constants/ ├─ helpers/ routers/ - 라우터 App.js - 렌더링할 것 index.js - entry 포인트

노션

오늘 한 것

✅ 내 코드 설명하기 & 코드 리뷰 받기

• 오늘 소통에 있어서 미숙한 점을 참 많이 느낀 것 같다. 내 코드 전체를 다른사람에게 설명해본 적이 없어서 많이 버벅거렸다.앞으로 내 코드를 남에게 설명할 일이 많을텐데 좀 더 남을 이해하기 쉬운 방향으로 설명할 수 있는 능력을 키워야겠다는 생각을 했다. 긴장을 해서 많이 버벅거리기도 했는데 이건 많이 하다보면 충분히 개선될 거라고 생각한다.
• 프로젝트를 왜 이렇게 구성했는지, 프로젝트 진입점부터 시작해서 요구사항을 어떤 로직으로 구현했는지를 중점으로 설명하는 연습을 하면 좋을 것같다. 핵심적인 기능의 로직은 따로 빼서 설명하면 더 좋을 것 같다.
• 나는 다른 분들 코드 리뷰를 할 때 syntax적인 부분을 집중해서 봤었는데, 로직에 대해서도 보고 고민해보는 시간을 가진 후 로직관련 리뷰도 남기면 좋을 것 같다. 그리고 내 말이 다 옳은 것이 아니니 꼭 권유/의문 형태로 리뷰를 남길 것!

✅ 클린코드 학습

• 클린코드를 측정할 수 있는 단위는 WTF 단위 뿐..! 남이 내 코드를 봤을 때 WTF이 덜 나오게 노력하자!
• 중구난방 내 맘대로 지은 변수이름들을 공통된 의미를 갖는 단어를 써서 읽기 편하게 만들어줘야 할 것 같다.
• 함수는 늘 자기가 맡은 한 가지의 행위만 하도록!
• 함수를 생성할 때 순수함수로 만들도록 노력하자. 순수함수로 만들기 위해서는 parameter를 flag로 쓰지 않는 것이 가장 중요할 것같다. parameter를 flag로 써서 조건 분기를 하는 순간 함수는 하나의 동작이 아닌 여러개의 동작을 하게 되어 단일 책임원칙에도 어긋나게 된다.
• 사이드 이펙트를 피하기

✅ 선발과제 리팩토링

클린 코드를 학습한 후 보인 내 코드의 문제점

1. 변수 / 함수 이름이 중구난방

• 함수 이름 같은 경우 보통 동사로 시작되게 네이밍을 하는데 함수의 의미를 잘 전달되게 하는 동사를 찾는 것이 어렵다. eventhandler의 경우 handle~~의 형태로 함수명을 짓는데 그 외의 것들도 나름의 규칙을 갖고 작명하면 좋을 것 같다.
• 같은 List형태의를 갖는 컴포넌트인데 어떤 곳에서는 그냥 복수형으로 컴포넌트이름을 짓고, 어떤 곳에서는 [~]List라는 형태로 이름을 지었다. 통일해주자.

  2. 여러 곳에서 공유되는 함수도 아닌데 utils 폴더에 정리

• 공통적으로 쓰는 함수 / 단일 컴포넌트에서 쓰는 함수 모두 utils 폴더에 정리했다. utils 폴더를 만든 이유가 다른 컴포넌트에서도 사용하는 함수들을 분리해놓기 위함인데, 거기에 굳이 단일 컴포넌트에서 쓰는 함수를 정리할 필요가 없는 것같다. 단일 컴포넌트에서 쓰는 함수는 그냥 컴포넌트 내에서 정리해도 괜찮을 것 같다.
• 또 utils보다는 helper/common이라는 이름이 직관적으로 폴더 구조를 이해하기 더 쉬울 수 있을 것 같다. 나

  3. 코드의 중복성

• 이메일 validation/비밀번호 validation을 할 때 거의 같은 로직인데 따로 함수를 만들어서 사용했다.
• 이메일 validation과 비밀번호 validation에서 다른 점은 validation을 할 때 사용하는 Regex 표현식 뿐이다. regex를 이용해 조건을 테스트하고, 테스트 결과에 따라 state를 업데이트한다. 이 로직을 함수로 만들고, 이메일/비밀번호 regex만 바뀌게 해서 좀 더 공통적으로 사용할 수 있는 형식으로 바꾸는 게 좋을 것 같다.

  4. 굳이..?싶을 정도로 너무 세세하게 컴포넌트를 분리

• styled-component를 써서 만든 컴포넌트를 사용해서 가독성 좋게 표현할 수 있기 때문에 굳이 Style만 지정해놓은 컴포넌트를 따로 파일로 빼놓지 않아도 될 것 같다. 너무 세분화해도 좋지 않고, 너무 뭉쳐놔도 좋지 않다. 뭐든지 적정한 지점을 찾는 게 가장 어려운 법이다. 그 지점을 찾을 수 있도록 연습해보자.

✅ 아쉬웠던 점

• 첫 날이라 좀 준비가 미흡했던 점이 많았던 것 같다. 회의에 참여할 때는 늘 논의할만한 것들을 생각해가고, 논의할만한 것에 대한 의견도 꼭 준비해가자.
• 의견을 내놓기 전에는 왜 이런 의견을 냈는지도 추가해서 설명하는게 설득력을 높이기 좋을 것 같다.

요즈음 취업을 준비하는 사람들이라면 '개발자를 꿈꿔보세요! 개발자 붐입니다!'라는 내용의 광고, 뉴스들을 심심치 않게 보게 됩니다. 실제로 요즘 많은 사람들이 '개발자'라는 직업에 도전하고 있습니다. 이런 상황에서 기업들은 수많은 지원자중에서 개발에 대한 열정이 있고, 실제 개발을 할 때 잘 어우러질 수 있는 지원자를 찾아야 합니다. 하지만 많은 사람들이 입사하기 전 공부하는 내용은 실무와는 꽤 많이 다릅니다. 공부하는 단계에서는 실무에서 어떤 프로세스를 밟아 개발이 진행되고, 어떤식으로 소통을 하는지 정확히 알 수 없습니다. 이 점 때문에 지원자가 실제 회사에 입사해 업무를 맡게 되었을 때 적응 기간도 오래 소요되고, 기업 입장에서도 너무 많은 것을 가르쳐야 하는 상황이라고 생각합니다. 원티드 프리온보딩 코스는 지원자가 실제 기업의 프로세스와 다른 이들과의 협업 과정을 경험을 할 수 있게 해 줄 것입니다. 실무에 가까운 환경에서 학습을 한 사람에게 프리온보딩의 참가기업에 지원하게 해 기업입장에서도 원하는 인재를 좀 더 쉽게 찾을 수 있게하기 위해 코스 참가자가 참가 기업에게 지원하는 제도가 있는 것 같습니다.

지원하고 싶은 참가 기업

• 스티비 https://www.wanted.co.kr/wd/105028
• GNA컴퍼니 https://www.wanted.co.kr/wd/99416
• 트립비토즈 https://www.wanted.co.kr/wd/72388 이 세 회사에 가장 지원해보고 싶고, 나머지 기업도 모두 지원해보고 싶습니다!

리액트 구조 https://www.xenonstack.com/insights/reactjs-project-structure

총 5시간이나 주어졌고, 과제도 비교적 쉬웠는데 참 아쉽다. 시간도 충분했는데, 평상시에 비동기 처리를 얼마나 대충했는지 알수 있었다..,^^

고민해볼 것

앞으로 타임어택식으로 개발해보고 시간내에 개발 못한 부분을 집중적으로 파봐야 할 것 같다.

• 시간이 아~~주 오래걸리는 작업일 경우에 사용자에게 어떤 문구를 어떻게 안내할 지 고민해볼 것.
• 브라우저 종료 시에도 데이터를 유지하려면 서버에 임시 데이터를 일정 주기로 저장하고, 새로 접근할 때마다 => 회원 시스템이 있을 경우에만 가능할 듯 싶고, 서버와의 통신이 많아진다는 단점이 있음
• 브라우저의 로컬스토리지는 브라우저 종료시에도 남아있다. 임시 데이터를 저장해놓는 용도라면 로컬 스토리지를 쓰는 것도 좋을 것이라고 생각했다. 그런데 보통 폼에 넣는 데이터는 유출되면 안될 경우가 많아서.. 암호화를 하거나 해야할 것 같은데 어떻게해야할 지 고민해볼 것!
• 프론트단에서 수동으로 캐시 조작할 수 있는 방법 찾아보기
• 폼에 데이터를 입력할 때 가장 기초적인 방식으로 계속 사용해왔다. 이렇게하면 한글자 입력할 때마다 스테이트가 업데이트되면서 리렌더링이 계속 된다. 당연히 최적화 해줘야 할 대상이다. Throttling이나 Debounce를 이용하면 입력할 때마다 스테이트 업데이트가 되지 않을 것 같은데 이 경우에 DOM에서 element의 value를 가져와 state를 업데이트해줘야 할 것 같다. 이게 맞는 방법인지는 다른 사람 코드를 보면서 계속 고민해봐야 할 듯..(ref를 사용해야한다는 뜻!)
• 알다시피 상위 컴포넌트가 리렌더링 => 하위 컴포넌트도 리렌더링 됨. React.memo를 적극활용해야 할 것 같은데 아직 익숙치가 않다.. 연습 또 연습!

Create a Next.js App

리액트를 빌드할 때 해야하는 것

1. 웹팩같은 번들러로 번들링, babel같은 컴파일러로 commonJS형태로 변환
2. 코드 스플리팅 같은 최적화가 필요함.
3. 성능과 SEO를 위해 pre-render이 필요하고 그와 동시에 SSR 또는 CRS필요
4. data store에 웹 앱을 연결시키기 위해 몇몇 서버사이드 코드를 작성해야 할 것.

Next.js : 리액트 프레임워크

1. 위의 4가지에 대한 해결책을 모두 제공해줌.
2. 특징
   • 직관적인 페이지 기반의 라우팅 시스템(+다이나나믹 라우트 제공)
   • 프리렌더링이 지원됨.
   • 자동적으로 코드 스플리팅(더 빠른 페이지 로딩 지원)
   • Built-in CSS, Sass , CSS-in-JS 지원
   • 개발환경에 빠른 새로고침을 제공
   • 서버리스 기능으로 API 엔드포인트를 구축하는 API 라우팅

Blog 만들기 예제

Navigate Between Pages

Pages in Next.js

• 파일 이름에 기반해 라우팅 됨. 즉, pages폴더 안에 원하는 대로 파일 구성해주면 됨.
• 컴포넌트는 아무 이름이나 써도 되지만, export default 형태로 꼭 export해주어야 함.

ex. 
1. 'pages/index.js'는 '/' 라우트
2. 'pages/post/first-post.js'은 '/posts/first-post'로 라우트.

• Link Component

  • Link컴포넌트 === a tag.

  • href 속성에 route주소 알려주기.

    import Link from 'next/link'
    
    <Parent-Component>
      <Link href="/psots/first-post">go to page</Link>
    </Parent-Component>

  • a태그 스타일을 입히고 싶다면 아래처럼

    <Link href="/">
     <a>Back to home</a>
    </Link>

• Client-Side Navigation

  • 클라이언트 사이드 네비 : 자바스크립트를 이용한 페이지 전환. 즉, 브라우저에 의해 실행되는 기본 네비게이션에 비해 빠르다.
  • 자바스크립트를 이용 ⇒ 페이지의 모든 내용을 새로 가져오지 않음(실제 css background 지정하고 다른 페이지 넘겼다가 다시 오면 배경색 유지됨)
  • a태그이용하면 브라우저가 fully-refresh할 것임.(로딩 속도에 별로 안좋겠져~)

• Code splittnig and prefetching

  • 자동적으로 코드 스플리팅이 됨.
  • 각 페이지에 필요한 것만 로드함. ⇒ 빠른 로딩이 가능하게 함.
  • 요청한 페이지의 코드만 로딩하므로 페이지는 다른 페이지와 분리되어 있음 ⇒ 특정 페이지가 에러를 발생시키더라도, 어플리케이션의 나머지 부분은 여전히 동작함.
  • 프로덕션 빌드에서 Link 구성요소가 브라우저의 뷰포트에 나타날 때마다 Next.js는 자동으로 링크된 페이지의 코드를 백그라운드로 프리페치합니다.(넘어갈 페이지의 데이터가 프리페치되어 미리 준비되어 있다고 보면 됨)

Assets, Metadata, and CSS

css를 추가해봅시당~(CSS, sass 지원)

Assets

• ‘public’폴더(가장 상위 레벨)에서 static assets 제공 가능
• public폴더 안에 있는 파일들은 참조될 수 있음
• public 디렉토리는 ‘robots.txt’(google site verification)에도 유용함

image

• public/images/[내이미지] 저장
• public이 static files의 root로, public안의 주소를 적어주면 됨.

  jsx
<img src="/images/[내이미지] "/>

그러나 위와 같이 그냥 img태그를 쓰면 생기는 문제점이 있음

• 다른 화면 사이즈에 대한 핸들링 해야함
• 써드파티 툴/라이브러리를 이용해 이미지 최적화 해야함.
• 이미지가 뷰포트에 있을 때만 로딩 됨

Image Component and Image Optimization

• ‘next/image’는 HTML의 img태그를 모던 웹애 맞게 확장시킨 것.
• 기본적으로 이미지 최적화를 제공함(resizing, optimizing, WebP같은 현대적 포멧으로 이미지 제공)
  • ⇒ 작은 사이즈의 스크린에서 큰 이미지를 들고오지 않아도 됨
  • ⇒ 차후 미래의 이미지 포맷을 자동적으로 적용할 수 있음.
• 외부 데이터 소스여도 자동적으로 최적화 해줌.

Using the Image Component

• 유저들이 이미지를 요청하면, 그 때 최적화가 진행된다(빌드될 때 최적화x ⇒ 이미지가 몇개든 빌드 시간은 변화가 없음.)
• 이미지는 기본적으로 ‘lazy loading’. 이미지가 뷰포트안에 들어왔을 때 로드됨.
• Images are always rendered in such a way as to avoid Cumulative Layout Shift, a Core Web Vital  that Google is going to use in search ranking(SEO에 유리한 방식으로 렌더링 됨)

Metadata

• 컴포넌트를 이용해 각 페이지의 metadata 수정 가능.

<Head>
  <title>Create Next App</title>
  <link rel="icon" href="/favicon.ico" />
</Head>

Third-Party JavaScript

• cdn으로 다른 라이브러리나 소스를 가져올 때
• Script 컴포넌트 사용. <Script src=”link” / >로 들고옴.

<Script
        src="https://connect.facebook.net/en_US/sdk.js"
        strategy="lazyOnload"
        onLoad={() =>
          console.log(`script loaded correctly, window.FB has been populated`)
        }
      />

속성은 따로 봐야할 것 같음
1. strategy : 언제 써드파티 스크립트가 로드되어야 할 지 정함. 2. onLoad : 스크립트가 로딩을 끝낸순간 실행된다.

CSS Styling

• styled-jsx : CSS-in_JS library
• 다른 css,scss 추가는 react 때랑 똑같이 하면 됨.
• 아래와 같이 사용해야 함!(css에 이름 붙여 import하고, className에는 css이름.사용할 클래스 로 지정해주어야 함)
• 이렇게 css modules를 이용하면 독창적인 이름을 알아서 지어줌.

// components/layout/layout.module.css
.container{
    max-width: 36rem;
    padding : 0 1rem;
    margin : 3rem auto 6rem;
}

// components/layout/layout.js
import styles from "./layout.module.css"

export default function Layout({children}){
    return <div className={styles.container}>{children}</div>
}

Global Styles

• 모든 페이지에 공통적으로 적용되기를 원하는 전역 css가 있다면?
• pages/_app.js 파일 생성

import '..styles/global.css'

export default function App({ Component, pageProps }) {
  return <Component {...pageProps} />
}

• 이 _app.js에서 global CSS를 추가할 수 있다.(다른데선X) 단순히 import로 불러와주기만 하면 됨!

Using classnames library to toggle classes

(조건에 따라 클래스 바꾸기 위해서는 classnames 라이브러리 쓰는걸 춫천추천!)

[classnames](https://github.com/JedWatson/classnames) is a simple library that lets you toggle class names easily. You can install it using npm install classnames or yarn add classnames.

Please take a look at its documentation for more details, but here’s the basic usage:

• Suppose that you want to create an Alert component which accepts type, which can be 'success' or 'error'.
• If it’s 'success', you want the text color to be green. If it’s 'error', you want the text color to be red.

You can first write a CSS module (e.g. alert.module.css) like this:

.success {
  color: green;
}
.error {
  color: red;
}

And use classnames like this:

import styles from './alert.module.css'
import cn from 'classnames'

export default function Alert({ children, type }) {
  return (
    <div
      className={cn({
        [styles.success]: type === 'success',
        [styles.error]: type === 'error'
      })}>
      {children}
    </div>)

Pre-rendering and Data Fetching

프리 렌더링

• Pre-render : next.js는 기본적으로 모든 페이지를 프리 렌더링하고 있다.(즉, Next.js는 사전에 각 페이지에 대한 HTML을 만들어 둔다.)
• 프리 렌더링 될 때 최소한의 js만 남기게 되고, 로딩될 때 js를 실행시켜 fully interactive하게 되어진다.(이 과정을 hydration이라고 함)

Two Forms of Pre-rendering

1. Static Generation: 빌드하는 동안 HTML을 생성하는 프리렌더링 방식. 프리렌더링된 HTML은 요청이 들어올 때 재사용된다.

1. Server-side Rendering: : 요청이 들어오면 각 요청에 대한 HTML을 만드는 프리렌더링 방식

Per-page Basis

• Next.js는 각 페이지마다 어떤 프리렌더링 방식을 사용할지 정하게 한다.(페이지마다 다른 프리렌더링 방식을 사용할 수 있음)

When to Use Static Generation VS Server-side-rendering

Static-Generation 추천

• 일반적으로 Static Generation을 추천. HTML 한 번 만들어주고 재활용이 가능하고, CDN으로 제공해 속도가 빠름
• 아래와 같은 사이트에서는 Static Generation이 유리
  • 마케팅 페이지, 블로그 포스트, 쇼핑몰 상품 리스트, Q&A, documentation ...
• 사용자의 요청 이전에 페이지를 미리 렌더링해둬도 된다 ⇒ Static Generation 사용!

Server-side rendering 추천

• 사용자의 요청 시에 그 요청 정보를 가지고 렌더링을 해야하는 경우라면, Server-side rendering을 추천!
• 데이터가 자주 업데이트되고, 요청마다 페이지의 내용이 바뀌는 경우에 Server side rendering
• Static Generation보다는 느리지만 내용은 언제나 최신! 혹은 pre-rendering을 하지 않고 client-side js를 사용하는 방법도 있음.

Static Generation with and without Data

• Static Generation의 경우에 데이터가 있어도, 없어도 가능.
• 외부 데이터 없이 제작 가능 ⇒ 그냥 앱이 빌드될 때 정적으로 HTML페이지가 생성됨.
• 어떤 페이지는 외부 데이터를 먼저 불러와야 렌더링이 가능한 경우가 있음 ⇒ 요건 getStaticProps를 사용해서 처리 가능(Data Fetching ⇒ Static Generation)

Static Generation with Data using getStaticProps

• getStaticProps ⇒ async function.

export default function Home(props) { ... }

export async function getStaticProps() {
  // Get external data from the file system, API, DB, etc.
  const data = ...

  // The value of the `props` key will be
  //  passed to the `Home` component
  return {
    props: ...
  }
}

Essentially, getStaticProps allows you to tell Next.js: “Hey, this page has some data dependencies — so when you pre-render this page at build time, make sure to resolve them first!”

---
title: 'Two Forms of Pre-rendering'
date: '2020-01-01'
---

Next.js has two forms of pre-rendering:**Static Generation** and**Server-side Rendering**. The difference is in**when** it generates the HTML for a page.

-**Static Generation** is the pre-rendering method that generates the HTML at**build time**. The pre-rendered HTML is then_reused_ on each request.
-**Server-side Rendering** is the pre-rendering method that generates the HTML on**each request**.

md맨 위의 -- -- 사이의 title과 date.는 metadata임
이것은 gray-matter라는 라이브러리로 파싱이 가능함.
*/

Pre-rendering and Data Fetching하는 곳 제대로 안봤음 주의해서 볼것!

• 내가 무조건 최신의 데이터를 들고올 필요는 없다 ⇒ server side rendering사용하면 되는데, 이 때는 getServerSideProps라는 함수를 이용해야 함.
• Client-side Rendering의 경우 사용자의 요청에 따라 최신 검색이 필요할 경우인데,

SWR

• SWR : 데이터 페칭을 위한 리액트 훅.
• 클라이언트 사이드에서 데이터를 패칭해야 할 경우 적극 추천! 약간 useQuery 훅 쓰는 거랑 비슷함. {data,error} = useSWR(’’,~) 이런식으로.

Dynamic Routes

Page Path Depends on External Data

• page path가 external data에 의존하는 경우
• 그니까 이런거임
• posts 폴더에 있는 컴포넌츠들 이름을 가지고 라우트
  • path : /posts/ , 는 posts폴더에 있는 파일의 이름.

Overview of the Steps

1. [id].js파일을 만듦 . [로 시작하고 ]로 끝나는 이름을 갖는 페이지 ⇒ 다이나믹 라우트임
2. export async function called ‘getStaticPaths’. 해당 함수는 id로 사용가능한 값을 반환한다.
3. 마지막으로 getStaticProps가 필요. → 주어진 id를 이용해 블로그 포스트에 필요한 데이터를 패치 . getStaticProps는 params를 제공함.

Dynamic Routes Details

Here is some essential information you should know about dynamic routes.

Fallback

• getStaticPaths에서 return 내용에 {fallback:false}를 넣어서 보냈음. 근데 fallback이 머죠?
• if fallback is false ⇒ 결과가 404인 path는 리턴X
• if fallback is true, getStaticProps의 행동이 변함
  • getStaticPaths에서 리턴된 paths이 렌더될 것임

Dynamic Routes 맨 마지막 페이지 덜함!~(22.02.19)

API Routes

Deploy

사용자가

• 사용하기 익숙한 형태로,
• 로딩 지연시간이 최대한 짧게,
• 사용하기에 불편함이 없도록(응답이 안됨. 알림 메시지가 안떠서 진행상황 전혀 알 수 없음, 취소 버튼 없음...),
• 더불어 사용하기 편하도록(입력 마쳤을 때 자동으로 다음 입력란으로 포커싱 혹은 페이지 넘김, 한 눈에 파악하기 편한 UI ...)

서비스를 지원해야 한다.

코드를 가볍게

• 코드를 가볍게 하기 위해선 역시 코드양을 줄이는 게 최고다!
  • 그렇다고해서 코드를 너무 압축해서 다른 사람이 코드를 알아보지 못한다면 안된다.
• 안쓰는 CSS 정리는 꼭 해주자
• 번들링할 때 minimize해주자

코드 스플리팅

• 코드 스플리팅 => 하나의 파일로 번들링x 특정 기준에 따라 몇 개로 나눠서 파일을 번들링,실제로 사용될 때 쪼갠 것을 로딩하도록 해서 초기 로딩 시간이 너무 길어지지 않도록 함.
• 코드가 하나의 js파일로 번들링이 되어 있으면 초기 로딩시간이 길어지므로 당연히 좋지않음.
• 방법1) React.Lazy 사용(SSR에도 곧 도입된다고 문서에 적혀있음)
• 방법2) 동적 import 사용
• 방법3) webpack을 이용한 코드 스플리팅
• 코드 스플리팅 가장 간단한 기준 => 페이지 별로 나누기

SEO(Search Engine Optimization)

• 구글 서치봇 => 웹 페이지를 크롤링해서 검색할 때 사용함. 그러면 웹 사이트가 검색엔진의 상단에 뜨게하기 위해서는 봇이 크롤링을 잘 해갈 수 있도록 해주어야 함
  • 메타 데이터, 타이틀을 페이지별로 잘 뜨게 해주자. - React의 경우 React Helmet을 이용해 각 페이지 별로

SSR(ServerSide Rendering)

• SPA의 경우 SEO 최적화가 힘듦. 그럼 페이지를 만들어서 응답하는 서버사이드렌더링을 사용해 meta, title,...을 페이지별로 잘 작성해서 크롤링이 잘 되도록 도와주면 좋겠다.
• React만으로도 SSR은 가능하지만, 사용하기 불편.
• SSR 프레임워크인 Next.js를 사용해보자
• Next.js의 특징
  • 직관적인 페이지 기반의 라우팅 시스템(+다이나믹 라우트 제공)
  • 프리렌더링이 지원됨.
  • 자동적으로 코드 스플리팅(페이지 뼐로 코드스플리팅. 더 빠른 페이지 로딩 지원)
  • Built-in CSS, Sass , CSS-in-JS 지원
  • 서버리스 기능으로 API 엔드포인트를 구축하는 API 라우팅

캐싱

• 수많은 요청과 응답.
• 모든 요청에 일일히 응답을 해주면 사용자 수가 적을 땐 괜찮을 수 있어도 사용자 수가 일정 수준 이상으로 많아지면 응답이 많이 지연될 수 있다.(모든 요청을 일일히 처리하고 응답해주어야 하기 때문에 처리하는데 시간이 많이 걸려 응답시간이 지연된다.)
• 사용자가 자주 요청하는 것은 캐싱해놓고 같은 요청일 경우 캐시에 저장된 내용을 반환해준다.(서버로는 요청x) 그러면 서버로 향하는 요청 수가 적어져 응답 할 거리도 적어지니 응답시간 지연률이 적어짐.
• http통신을 할 경우 GET 요청은 기본적으로 캐시를 사용한다.

하나의 상태를 여러 개의 스크린/컴포넌트에서 사용해야한다면? state managemen를 사용하지 않을 경우, 상위 컴포넌트에서 상태를 만들고 하위 컴포넌트로 props를 통해 넘겨주어야 함.(react는 단일 방향으로만 흐르도록 설계가 되어 있으니까) 그런데 전달해주어야 하는 depth가 너무 깊거나, 중간에서는 사용안하는데 단지 하위 컴포넌트로 해당 상태값을 넘겨주기 위해 props로 사용하지 않는 값을 받아야하는 경우가 있다.

쉽게 말해 state management란 글로벌하게 사용되는 상태를 따로 관리해주는 것.

1. Redux

순수 리덕스 + 리액트 리덕스 + 액션,리듀서를 작성하기 편하게 해주는 툴킷 + 비동기 처리를 쉽게 만들어 줄 thunks/saga .... 붙일게 좀 많기는 함.

2. Recoil

아직 공부한 지 얼마 안됐음 state라는 용어대신 atom이란 용어를 사용함