🥦브로컬리🥦 프로젝트 4일차

오늘 아침은 멘토님이 우리팀 Standup meeting에 참관하시며 시작됐다.

Standup Meeting

백엔드

• 어제 초기세팅,models.py 작성후 merge완료
• API 기능정의서 작성 예정
• api 작업 시작 예정
• 어제 DB 데이터를 통일화시키기위한 구글스프레드 시트에 CSV 파일 작성 및 더미데이터 넣기

프론트

• 오늘부터 프론트 스케줄
  -> 아침미팅
  -> 오후 - 각자 코딩
  -> 저녁 8시 이후 - 프론트 모두 모여서 코딩, 미팅
  - 이때 하루 동안 있었던 대부분의 토론, 질의응답을 함
  - 하지만 당연히 필요할 때는 긴급회의, 질문 가능!!
  
• 메인 페이지가 상품 리스트 페이지이기 때문에 상세 리스트 카페고리별 url 변경 예정
  -> query 사용해야 할 예정
  -> useParams / useLocation 을 찾아볼 예정
  -> /products/:id (상품 상세페이지 url 예정)
  
• modal 컴포넌트 만들 예정

멘토님의 리뷰

• 사후 log 작성을 하고 있는 것은 좋음
• 추가로 사전 log 도 하면,
  -> 미리 블로커에 대해서 팀들이 모두 고민해 볼 수 있음
  -> 미팅이 더 의미 있고 다른 팀원들이 빨리 다른 팀원들의 말을 이해할 수 있음
• 나중에 merge 된 기능끼리 합칠 때는 branch 를 새로 만들어서 연결 후 합치는 것이 좋음
• 주석 -> 최대한 없으면 좋지만 TO DO, TO FIX 부분은 주석 처리해줘도 괜찮음

프론트 미팅

• common.scss 에 variables 를 같이 작성했는데 분리해서 다시 push 할 예정임.
  • pull 받아서 지금까지, scss 에서 common 불러서 사용한 부분 variables 로 변경해야 함
  • 이유: variables에 있는 변수만 사용하기 위해서 불러야 하는데,
    common stle이 들어있는 common 파일을 계속 불러서 사용하면 css 부분들이 끊임없이 적용돼서 나중에 문제가 생길 수 있음
  • common.scss는 최상위인 index.js에 한 번만 적용하기
• 8시 모각코 할 때 의논할 부분이 있으면 미리 모각코 카드에 작성해서 미리 다른 팀원이 보고 고민할 수 있게 하기

Rest API 세션

• 다시 세션을 들어야 더욱 잘 이해할 것 같지만 Rest API 를 사용하는 이유와 큰 맨락을 알게 되었다.
• 내일 다시 공부해서 따로 블로그 작성 예정
• 월요일부터 백엔드와 통신을 많이 할 예정인데 전체적인 맥락을 알기 좋았다.

백엔드와 URL 미팅

• 상세리스트
  • 프론트 : menu, category, sort 값을 저장했다가
  • 백에서 정해지는 URL 로 만들어서 보내기
    • 백이 아직 web api 완료 전이라
      먼저 UI가 완성된 프론트에서
      백에서 필요한 키값과 endpoint로 사용할 부분을 고려해서 코드를 짜서 백엔드가 url/ api 완성되면
      fetch 하는 부분만 조금 수정해서 사용하기
  • NAV 에서 메뉴 클릭 시 어떤 메뉴 클릭했는지(query 변경해서 보내 달라고 하기
    • path 부분 ?쿼리 로 값 만들어서 보내기
  • product 눌렀을 때 product ID 만 넘겨주면 됨
    • product ID 는 전체(모든 메뉴들 다 합친 데이터에서) 유일함
    • product ID 만 보내면 상세 페이지 데이터 받을 수 있음
• 장바구니
  • 주문한 product Id 만 토큰과 함께 보내면 -> 장바구니 아이템들 전체 받을 수 있음
  • 프론트는 product Id만 준비하면 됨
  • 상온, 냉장 상품들은 분류되지 않고 통으로 보내기로 했기 때문에 -> 프론트에서 분류해서 보여줘야 함
  • 수량변경 부분, 삭제 부분은 나중에 다시 이야기하기
• 주문서
  • 주문 누르면 주문이 완료되고
  • 주문서 ID 받아서 완료되었다는 알람 뜨게 하기
  • 장바구니에서 방금 주문한 부분은 삭제되고(프론트 입장에서 장바구니 페이지에서 원래 하던 fetch 그대로 실행하면 됨)
  • 장바구니 화면으로 가면 장바구니에 남은 아이템들만 보임

성장한 코드

productList

처음의 계획

변화된 부분

• route 부분이 많았는데 생각해 보니 route 는 path 를 변경해 주는 것이고 프론트 내부가 변화될 때 사용하는 것이고
  안에 부분만 변경되면 대부분 fetch 면 된다는 것을 알게 되었다.
  (백엔드와 통신하는 것이 처음이다 보니 참 많이 다르다. 이런 부분을 알게 되는 것이 정말 즐겁다!!!)

카테고리 고르는 코드(한개만 선택되면 됨)

처음 코드

• 이부분에 대해 ture, false 로 관리하려고 했었다.

const [sortCheck, setSortCheck] = useState([true, false, false]);
setSortCheck(sortCheck.map((_, i) => (i === id ? true : false)));
className={`sortBtn ${sortCheck[i] ? 'checked' : ''}`}

변경된 코드

• 생각해 보니 언제나 값이 1개만 존재한다.
• 그렇다면 그 값만 저장하면 되고 그 값과 같으면 / 아니면 이라는 로직이면 된다고 생각되어
• 리팩토링 했다.
• 더 간단하고 보기 좋은 코드가 되었다!!!!

const [sortCheck, setSortCheck] = useState(0); 
setSortCheck(id);
className={`sortBtn ${sortCheck === i ? 'checked' : ''}`}

오늘의 성장

• 백엔드와 만나는 fetch 를 위해 어떤 부분을 고려해야 하는지 오늘 많이 배우게 되었다.
• 데이터 테이블을 보고 대략 백엔드에서 필요할 부분을 예상할 수 있게 되었다
• 프론트에서 url을 바꾸어 주는 것은 프론트끼리 소통하기 위해 사용됨을 알게 되었다.
• 이렇게 알려주지 않으면 페이지가 바뀌면 뒤 페이지를 담당하는 프론트는 앞에서 무슨 일이 일어났는지 알지 못한다.
• 앞 페이지의 프론트가 뒤 페이지 프론트에서 할 fetch를 고려한 path 를 보내줘야 한다.
• url이 백엔드와의 소통을 위해서만 바꿔주는지 알았는데 앞페이지, 뒤페이지 프론트 , 백엔드- 3 부분을 모두가 고려해야 하는 부분이였다. 사실 fetch가 일어나는 페이지에서 가지고 있는 url은 이전 페이지에서 준 url 이다.