[WANTED] ASSIGNMENT_4

jun gwon·2022년 11월 8일
0

원티드 프리온보딩

목록 보기
8/14
post-custom-banner

ASSIGNMENT_4

네번째 과제의 요구사항

과제의 대략적인 요구사항은 아래와 같았습니다.

  1. 피그마로 페이지 디자인 시안이 주어져있고, 그것에 따라 구현합니다
  2. 페이지는 총 2개로, 각각 Header와 Nav를 공유합니다
    2-2. 페이지 이동시 Nav에 있는 버튼은 이동한 페이지에 따라 디자인이 다르게 적용되어야 합니다.
  3. 1페이지에서는 광고 결과 데이터를 받아와 차트를 구성하고, 날짜 및 옵션에 따라 차트가 업데이트 되어야 합니다.
  4. 2페이지에서는 광고 정보 데이터를 받아와 카드 형식으로 데이터를 나타내고, 수정을 할 수 있어야합니다.

시작하기에 앞서

초기 셋팅

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

추가적으로, 이번 과제에서는 API가 별도로 주어지지 않고 JSON 파일만이 주어졌기 때문에, public에 server 폴더를 만들고 거기에 보관하였습니다.

gitMsg 규칙 변경

🎨 ui : 새로운 CSS관련 디자인에 대한 커밋
👏 chore : 파일 이동, 파일명 수정, 변수 제거 등의 자잘한 수정에 대한 커밋
📝 style : 공백 제거와 같은, 코드 스타일 혹은 포맷 등에 관한 커밋

과 같이 일부 커밋 규칙이 변경하였습니다.

기존 chore 규칙과 sytel 규칙의 경계가 너무 불분명하여, style 커밋은 자잘한 코드스타일에 대한 부분으로 제한하였습니다.
또한, ui 커밋을 따로 생성하여, 기존 feat커밋에 ui도 같이 겹치는 부분을 제거하기로 하였습니다.

진행 및 BestPractice를 만드는 방법

이전 방식과 크게 달라진 부분은 없었습니다.
원칙적으로는, 과제 진행일 마다 매일 모여서 각자 의견을 공유하고, 제출 전날 각자 코딩리뷰를 한 후, BestPractice를 선출하였지만, 이번 과제물은 완성한 분이 한분밖에 없어서 자동적으로 그 분이 선출되었습니다.

코딩구현

1. NavLink를 사용한 Button의 디자인 변경

 <NavLink 
   to="/" 
   className={({ isActive }) => 
     isActive 
       ? `${ServicePageButtonStyle} bg-[#EDEFF1] text-[#586CF5]` 
       : `${ServicePageButtonStyle}` 
   } 
 > 

사실 react-router-dom의 Link만 사용하여서 NavLink를 사용할 생각은 전혀 못했었는데, 팀원분의 정보 공유로 인해 손쉽게 페이지 이동에 따른 버튼의 디자인변경을 할 수 있었습니다.
NavLink는 클릭이 되어 페이지가 변경될시 className에서 isActive값을 주기 때문에, 이를 활용하여 버튼값의 디자인을 변경하였습니다.

2. json 파일로 promise 요청하기

이번 과제 같은경우 API가 전혀 주어지지 않고, JSON파일만이 주어졌습니다. 이것을 처리하기 위해서 어떠한 방식이 좋을지 토의해봤는데, json서버를 사용하거나, src 내에 data폴더에서 관리하여 불러오자는 의견등이 있었습니다. 하지만 팀원 한분의 의견으로 public에 json파일을 보관하고 해당 경로로 요청을 보내면 json 데이터를 API요청을 통해 받아오는것과 큰 차이없이 받아올수있다는 사실을 알게되었습니다.

정말 사소한것이지만, 이러한 발상으로 json파일을 코드에서 굳이 불러와 처리해줄 필요가 없다는것을 알게되어 좋았습니다.

예시) axios.get("/mockData/jsonFile.json")

3. useToggle 커스텀 훅의 재사용

이것도 사실 매우 단순하고 사소한것이지만, 지금까지는 bool값이 필요한 많은 부분에서 각각의 컴포넌트에서 useState를 사용하여 값을 생성하였습니다. 하지만 이러한 부분을 커스텀 훅을 사용하여 재사용하였고, 이후에도 추상화 하여, 재사용할 수 있는 부분이 있다면 커스텀 훅을 사용 해야겠다는 생각을 하게되었습니다.

 export const useToggle = () => { 
   const [toggle, setToggle] = useState(false); 
   const onToggle = () => { 
     setToggle(prev => !prev); 
   }; 
   return [toggle, onToggle]; 
 }; 
 
 //사용 방법 (드랍다운)
  const [listToggle, onToggle] = useToggle();
  
    <AdDropDownBlock onClick={onToggle}> 클릭시 토글값 변경
       {listToggle && <토글일시 보여줄 >}
	<AdDropDownBlock/>

4. Class를 사용한 service 및 context 사용

이전 강의에서 클린 코드를 위한 예시로서, OOP 관점에서 클래스가 하나의 관심사를 가지고 처리히먀, 또한 이것을 컨텍스트에서 값을 불러와 사용하는 예시를 강사님이 보여주셨습니다. 그래서 이번 프로젝트에서는 그러한 방식을 사용해보려 하였습니다.

//getAdList(type:string):Promise<adList[]>
export class AdListService {
  #httpClient;
  #Listpath;
  #endPoint;

  constructor(httpClient, endPoint = 'wanted_FE_ad-list-data-set.json') {
    this.#httpClient = httpClient;
    this.#endPoint = endPoint;
    this.#Listpath = 'ads';
  }

  getAdList(type = 'all') {
    return this.#httpClient.fetch(this.#endPoint).then(result => {
      if (result.status !== 200) {
        throw new Error('api Error');
      }
      const adsData = result.data[this.#Listpath];
      if (type === 'all') {
        return Promise.resolve(adsData);
      } else {
        return Promise.resolve(adsData.filter(adItem => adItem.status === type));
      }
    });
  }
}

주석을 통해서 인터페이스를 적어주었고, httpClient와 endPoint를 의존성을 주입하여 사용할수있게 설계하였습니다.

//context에서의 사용.. 처음에 값을 받아와 set으로 값을 넣습니다.
  useEffect(() => {
    adListService.getAdList().then(result => {
      setAdListData(result);
    });
  }, []);

5. 익숙치 않은 Lib를 사용하려한 경험

차트는 'react-chartjs-2' 를 사용해보려했고, 날짜를 표현하는 것은 airDatePicker를 사용해보려했습니다.
둘다 처음 사용해보는 Lib기 때문에 당연히 많은 부분을 해맸습니다.
결국 최종적으로 해당 Lib를 사용하여 과제물을 완성하지는 못하였지만,
모르는것에 도전한 경험이 좋았습니다.
완성은 못하였지만, chartJs는 배열을 사용하여 값을 주입하면 값이 자동으로 완성되고, DatePicker 또한 훅을 통해 값을 보관하면 손쉽게 사용이 가능하다는 점을 알게되었습니다.

그리고, 외부 Lib를 사용하는경우, 디자인은 무조건 2순위로 작업해야 한다는것을 절실히 깨닫게 되었습니다.
이번 과제물 같은경우 Lib의 디자인에 신경쓰느라 시간 Resource를 많이 소비하였고, 결과적으로 만족하지 못한 결과가 나온것 같습니다.

좋았던 부분 및 개선된 부분

  1. CSS 기능구현이 이전보다는 수월하게 진행되가는걸 느꼈습니다.
  2. 약간이지만, 반응형적인 디자인을 고려하여 페이지를 디자인한게 좋았습니다. grid와 flex의 혼합 사용등..
  3. 피그마에서 SVG를 따와서 조금 더 수월하게 진행할수있었습니다.
  4. styled componet를 사용한 컴포넌트화를 많은 부분에서 진행하였습니다.
  5. 항상 사용하던 컨테이너 패턴을 하지 않고 class와 context를 사용한 클린코드 형식을 도전해본 경험이 좋았습니다.
  6. NavLink를 사용하여 버튼의 디자인을 쉽게 적용이 가능하단점을 알게되어 좋았습니다.
  7. 비록 구현은 못하였지만, chart Lib를 어떻게 사용해야 하는지 간접적으로 알수있게 되어 좋았습니다.
  8. HTML의 select 태그를 사용하지 않고, DropDown을 구현하는 방법을 구상하고 구현하게 되어 좋았습니다.
  9. json파일을 public/server에 보관하여 해당 URL에 요청을 보내면 실제 API를 요청하는것처럼 사용할수있단점을 알게되어 좋았습니다.

아쉬웠던 부분

  1. 시간내 많은 부분을 완성을 하지 못한게 가장 아쉬웠습니다.
  2. chart를 사용하여 데이터를 표현하는것에서, 사실 디자인 부분은 2순위일것입니다. 가장 우선순위는 데이터를 보여주는것인데, chart의 디자인 부분을 다루는것에 시간을 너무 투자하였고, 결국 이것으로 인해 일정이 꼬여버린것 같습니다.
  3. class를 사용한 클린코드를 구현해보려했는데, 처음 쓰는 방식이다보니 좀 헤맸던것 같습니다. 그저 fetch값을 전해주면되는데, 클래스 내부에서 불필요한 Promise를 사용하는등, 이상한 구현과, 구현을 하는데 해맨 시간이 꽤 많았습니다.
  4. 관심사 분리 원칙으로서, 하나의 클래스에서 너무 세세하게 나누려 한것 같아 아쉬웠습니다. 나쁜 방법은 아니겠지만, 완성이 최우선 사항일텐데, 사소할 수도있는 부분에 많은 시간을 투자하는것은 좋지 않다고 생각하였습니다.
  5. url을 사용하여 페이지 이동 값 저장 또는 날짜 값과 같은것을 저장하는 방법을 생각하지 못한게 아쉬웠습니다.
  6. 수정하기 값을 전역값으로 저장하는 기능을 만들지 못한게 아쉬웠습니다.

배포 링크

(기간 내 미완성,작업기간 1.5일)
http://pre-onboarding-7th-2-2-9-june.s3-website.ap-northeast-2.amazonaws.com/

Git Repo

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

BestPractice 선정 결과

최종적으로 시간내 완성하신분이 한분밖에 없으셔서, 그분이 자동적으로 선출되었습니다.

진행 중 아쉬웠던 점

  • 과제 진행중에 스트레스와 피곤함을 많이 느꼈는데, 이것을 토의 진행중에 은연중에 한숨등으로 들어냈던점이 아쉬웠습니다. 스스로 힘들더라도 내색하지 않고, 파이팅한 느낌으로 진행하면 더 좋았을것 같습니다.

진행 중 좋았던 점

  • 미완성이긴 하지만, 역시나 개발에 몰입하는 경험이 좋았습니다.
  • 점점 팀의 규칙이 정형화 되어, 추가하거나 제거할 부분이 없어져, 신경 써야할 부분이 없어져서 좋았습니다.
  • 정보 공유 Page를 모아두는 wiki 생성 등, 조금 더 정보를 문서화 하는 방향을 찾을 수 있었습니다.
post-custom-banner

0개의 댓글