ASSIGNMENT_3

세번째 과제의 요구사항

세번째 과제의 요구사항은 대략적으로 이러하였습니다.

1. 피그마로 디자인이 주어졌고, 피그마 상의 디자인 및 기능을 구현하여야 했습니다.
2. 디자인은 모바일 기준으로, 360~450px까지 고려해서 제작되어야 했습니다.
3. API가 주어졌고, API의 상태에 따라 로딩 중, 차량없음 등이 나타나야했습니다.
4. 페이지는 두개로 나뉘어지며, 리스트 페이지와 상세페이지 두개로 나뉘어졌습니다.
5. 추가 요구사항으로 SEO를 구현하여, 카카오톡 및 페이스북에 공유시 일부 정보가 노출되어야 합니다.

• 과제 수행 시간 수요일 오전 0시~ 금요일 오전 9시 (약 2일)

시작하기에 앞서

초기 셋팅

초기 셋팅은 이전 과제물들과 동일하게 진행하였습니다.
불필요한 파일이 제거된 CRA를 생성하고,
ESLint,Prettier,husky가 설정이 된 repo를 main으로 올린 뒤, 팀원들이 모두 클론하여 각자의 브런치를 만들고 진행하였습니다.

코딩 컨벤션

코딩 컨벤션은 이전과 유사하지만, 추가적으로 loading과 error에 대한 상태값을 isLoading, hasError으로 표현하기로 하였습니다.

기존 코딩 컨벤션

• 컴포넌트의 ID사용은 지양한다.
• react의 state는 여러개 사용시 최소 집합을 찾아 사용한다.
• 컴포넌트의 이벤트에서 불필요한 익명함수를 사용하지 않는다. (예시: 함수의 인자가 event 하나인 경우)
• 코드를 설명하는 주석은 가급적 사용하지 않는다.
• 상수는 영문 대문자 스네이크 표기법(Snake case)를 사용한다.(예시: SYMBOLIC_CONSTANTS)
• 반환 값이 불린인 함수는 'is'로 시작한다
• const와 let은 사용 시점에 선언 및 할당한다.
• 함수는 사용 전에 선언해야 하며, 함수 선언문은 변수 선언문 다음에 오도록 한다.
• 이벤트 핸들러는 'on'으로 시작한다.
• 한 줄짜리 블록일 경우라도 {}를 생략하지 않으며 명확히 줄 바꿈 하여 사용한다.
  • 한 줄짜리 블록일 경우 {}를 생략할 수 있지만, 이는 코드 구조를 애매하게 만든다. 당장은 두 줄을 줄일 수 있겠지만 이후 오류 발생 확률이 높아 잠재된 위험 요소가 된다.
  • 단, map과 같은 화살표 함수의 암시적 반환은 허용한다.

진행 및 BestPractice를 만드는 방법

이전 방식과 크게 달라진 부분은 없었습니다.

기본이 개인과제로서 이뤄져야 하는 프로젝이트이고, 시간적인 여유가 없는 편이였기에 이상적인 BestPractice를 만들수는 없었습니다.

하지만 하루에 한번씩 토의시간을 가져, 각자 진행상황 및 정보를 공유하였고, 좋다고 생각하는 방법을 Discusions에 공유하여 장점을 자신의 프로젝트에 적용할 수 있도록 하였습니다.

선정방법

기본적으로 각자 repo를 진행하였고, 제출 하루전날에 Discusions에 배포 페이지와 함께 코드를 공유하였고, 제출날 오전 9시까지 각자 코드리뷰를 끝낸 후, BestPractice를 선출하였습니다.

코딩구현

개인적인 구현 과정에서 막혔던 부분의 List는 아래와 같았습니다.

1. CSS 관련 부분

해당 과제의 Header는 전통적인 Header 방식이였습니다.
EL1 Title EL2
타이틀은 중앙정렬, 나머지 EL은 각 왼쪽,오른쪽에 정렬된채로 나타면 되는 부분입니다. 쉬울수 있다 생각했던 부분인데, EL이 width를 먹어버리니, flex로 구현햇을때 justify-center와 같은 부분이 약간 어긋난채로 진행되었습니다. 결과적으로는 EL2는 원래는 없는 컴포넌트지만, spacer로서 EL1과 같은 크기를 주었고, flex의 설정중 flex-none 과 grow 설정을 통하여 해결하였습니다.

하지만 결과적으로 absoulte를 활용했다면 더욱 쉽게 해결할수 있지 않았나 생각하였고, 너무 flex에 의존하여 페이지를 구성하려 하지 않았나 반성하였습니다.

2. tag 정보를 받아오는 부분

해당 과제물에서는 Label과 같은, 태그를 선택하여 정보를 받아옵니다. 이 태그는 사실 API값으로 받는것이 아닌, 어느정도는 정해진 값이기때문에 상수등을 사용한 하드코딩이 어느정도 허용되는 부분이였습니다.

저는 이부분을 오해하여 API를 사용하여, 태그에 사용되어지는 2가지 타입의 정보를 2차원 배열로 타입 이름과 API 상의 VALUE를 넣고, 2차원 배열의 중복값을 제거하고, 이후 ENUM값에 따른 INFO VALUE값을 넣어주었습니다.

오해한 부분 또한 아쉽고 개발 리소스가 낭비된 부분이지만, 2차원 배열의 중복값을 제거하는 부분에서 시간이 오래 걸린것 같습니다.
2차원 배열의 중복값 제거는 결국 검색을 통하여 해결하였습니다.removeDup 함수

ENUM 타입기술... 

function getTagArr(carObj) {
  const allTag = carObj.reduce((acc, cur) => {
    let carInfo = cur.attribute;
    return [...acc, ['fuelType', carInfo.fuelType], ['segment', carInfo.segment]];
  }, []);

  const uniqueTag = removeDup(allTag);

  return uniqueTag;
}

function tagFiltering(carObj) {
  const allTag = getTagArr(carObj);
  const tagItem = allTag.map(tagArr => {
    if (tagArr[0] === 'fuelType') {
      return [...tagArr, fuelType[tagArr[1]]];
    } else if (tagArr[0] === 'segment') {
      return [...tagArr, setmentType[tagArr[1]]];
    }
    return null;
  });

  return tagItem;
}

3. 전역값을 활용하는 부분

1. 과제물의 요구사항은 상세페이지에서 뒤로가기 페이지 이동시 이전 정보값이 남아있어야 합니다. 마찬가지로 Tag 또한 선택된 값이 남아있어야 합니다. 페이지가 이동시 컴포넌트 자체는 리렌더링 됩니다. 때문에 이전값을 재 활용할수없었습니다. 저는 이부분을 React.memo를 활용하여 Tag가 리렌더링 되지 않도록 하고 싶었지만, 의존성적인 문제로 인해 쉽지 않았습니다. 결국 헤매다 Tag의 정보 또한 전역값을 선택하여 뒤로가기시 불러오도록 하였습니다.

전역값은 최소로 하는게 맞지만, 필요하다 생각하면 이용을 주저하지 않는것 또한 중요하다 생각하였습니다.

좋았던 부분 및 개선된 부분

• 컴포넌트화를 이전보다는 더 할 수 있도록 노력하였습니다.
• tailwind-styled-component를 활용하여 가시성을 조금 더 좋게 할 수있도록 노력하였습니다.
• 리액트의 state 사용을 가능한 최소화 하기 위해 노력하였습니다.
• 단순한 화면 구현 이외에도, 생각나는 오류를 최소한으로 할 수 있도록 노력하였습니다.

아쉬웠던 부분

1. CSS부분에서 막히는 부분이 부분부분 있어 생각보다 시간이 많이 걸렸습니다.(absolute의 설정, flex의 공간 설정 등)
2. 설정적인 부분을 미처 제대로 확인하지 못해 작동이 안되는걸 발견하는데 시간이 소요되었습니다.
3. 시간분배를 잘못하여, 제출일정까지 완성이 빡빡한채로 진행되었습니다. 그로인해 함수의 추상화 및 변수명, 변수의 사용, 디테일 페이지의 일부 컴포넌트 분리 등을 정리되지 않은채로 제출한게 아쉬웠습니다.
4. useEffect를 매 렌더링시 실행시키고, 조건문을 주어 실행 시키지 않는 방법등의, 해당 프로젝트에서 더 좋은 방법이 있는것을 진행중에는 미처 깨닫지 못한 부분이 아쉬웠습니다.
5. context 또는 redux와 같은 전역값을 언제 어디에 보관해주어야 할까를 빠르게 정하지 못해 헤맸던 부분이 있었습니다.
6. API와 피그마 상의 태그정보를 불러오는것을 잘못 해석하여, 개발 리소스의 낭비를 하였던 부분이 아쉬웠습니다.
7. component - container 구조의 파일작성을 하엿는데, 일부 컴포넌트(태그)에서 컨테이너에서의 데이터 주입이아닌, 직접적인 전역값을 불러와 사용하는것이 아쉬웠습니다.
8. 추가요구사항 REACT-SEO는 구현하지 못하였습니다.

배포 링크

(작업 기한 약 2일)
http://wanted-pre-onboarding-fe-7-june.s3-website.ap-northeast-2.amazonaws.com/

Git Repo

https://github.com/jun-05/pre-onboarding-7th-2-1-9

BestPractice 선정 결과

이전과 동일하게 Discusions을 통하여 의견을 나누고, 최종적으로 선정된 분의 과제물을 최종 과제물로 제출하였습니다. 이분의 코드에서 좋다고 생각하였던 부분은 아래와 같습니다.

NextJS를 처음 접해서 공부하고, 바로 프로젝트에 적용하신 분이셨습니다.
때문에 아래와 같은 점으로 저는 이분을 선정하였습니다.

• NextJS를 빠르게 습득하고 적용하시는 점이 정말 본 받고 싶었습니다.
• 프로덕트 완성을 여유롭게 하신점 또한 정말 본 받아야지 싶었습니다.
• 기본적인 요구사항 충족 뿐만 아니라, 세심한 부분 까지 신경쓰신점이 좋았습니다.
• 애니메이션 Lib를 잘못사용하게되면 어색할 수도있는데, 어울리게 구현하셨습니다.
• API에서 id는 있었지만, id를 받아 처리하는 부분이 없었는데, 이부분을 filter값을 사용하여 id값으로 페이지를 구현하였습니다.
• 세세한 부분, 전역 값이 있을때 뒤로가기를 누르면 값을 재활용하고, 없으면 전체를 모두 불러오는 등의, 세세한 처리가 좋았습니다.

선정 결과 링크(비공개)

진행 중 아쉬웠던 점

코드부분을 제외한 많은 부분이 개선되었다고 생각했습니다.
하지만 그래도 아쉬운 부분은 있었고, 그러한것은 아래와 같습니다.

• 초기셋팅에 알맞는 favicon을 공통된 CRA에 넣을것을 건의 하면 더 좋았을것 같습니다.
• 공유 코드 외, 정보 공유 사이트를 깃허브의 wiki를 사용하여 보관한다면 더 좋았을것이라 생각했습니다.
• gitMsg 규칙에서 일부 혼동되어 사용될 여지가 있는채로 프로젝트가 진행되었습니다.
• 문서 작업 및 템플릿 작업도 맡다보니, 시간 분배가 안되어 정작 본인의 프로젝트에 소홀히 했던 부분이 있던것 같습니다.

진행 중 좋았던 점

• 이전과 마찬가지로, 짧은 시간내 몰입하여 프로덕션 개발을 완성하는 경험을 하였습니다.
• 팀원 분들의 정보공유가 조금 더 활발히 진행될 수 있었던것 같습니다.
• 토의시 진행을 조금 더 매끄럽게 진행할 수 있었던것 같습니다.
• Discussion을 적극적으로 활용하여 매 토의 내용을 가능한 모두 적을 수 있도록 노력하였습니다.
• Discussion에 올리는 양식에서 필요한 부분은 공통적으로 기술하여 조금씩 규격화 하게되어 코드리뷰시 이전보다는 매끄러워진 부분이 좋았습니다.
• readMe 템플릿을 작성하고 공유하여, 선정된 분이 readMe 작성시 도움이 될 수 있도록 한 점이 좋았습니다.
• 마크다운에 조금 씩 익숙해 져가며, permaLink, 토글 및 기타 사용법에 대해 익숙해진 부분이 좋았습니다.
• AWS S3를 사용하는 배포에 대해서는 매우 익숙해진것 같습니다.