프로젝트 소개

우리 프로젝트를 통해서 도출하고자 한 웹 서비스

• 맞춤형 운동과 식단 제공
• 운동 및 건강 정보 공유 커뮤니티
• 트레이너 매칭 수수료 기반의 비즈니스 모델

해당 웹 서비스가 시장에서, 사용자들에게 전달하는 제품적 가치와 의미

• 운동에 관심이 많아진 현대인들에게 서로의 운동을 공유하고, 원하는 PT선생님의 정보를 확인 후 매칭하거나, 자신의 운동을 기록, 자신에 맞는 식단과 운동법을 추천해 사용자에게 보다 쉽고 재미있는 운동을 접하게 하기 위함

해당 웹 서비스를 개발하기 위해 소요된 모든 시스템 설계 (디자인) 도면, Workflow, 고민사항 등

• 이미지의 크기를 크게 하여 운동에 대한 정보를 보다 더 정확하게 전달하고, 검정색배경에 강렬한 노란색을 통해 파워풀한 느낌이 들게 디자인함.

기술적으로 구현해 낸 실제 웹 페이지 모습 (각 페이지 별, 데이터 별 요소들의 기획 배경)

• 운동기록을 사용자에게 쉽게 표현하기 위해 차트를 사용
• 커뮤니티 기능보단 메인페이지와, PT선생님의 정보가 보다 쉽게 전달되기 위해 정보를 보여주는 페이지에 중점을 뒀다.

팀원간 효과적으로 소통하여 이루어낸 업무의 능률적인 개선 프로세스

• aws를 통해 프론트엔드와 백엔드의 테스트가 보다 쉽고 원할하게 진행이 되었다.
• Trello를 통하여 업무 진행상황을 체크하며 일정을 관리했다.

스스로 짚어보는 해당 웹 서비스의 아쉬운점 그리고 개선점

• 실력이 부족한 팀원을 잘 이끌지 못해 프로젝트의 완성도가 떨어진 점
• 다양한 기술스킬을 써보지 못한 점

내 역할

• ProductManager
• 로그인 및 회원가입(간편로그인)
• 마이페이지 및 수정
• 제품 구독 페이지
• 운동기록 페이지

checkList

FrontEnd - TODO

[x] 로그인 페이지나 [x] 회원가입 페이지나 [x] 네이버 및 카카오 간편로그인나 [x] 회원가입 페이지나 [x] 마이페이지나 [x] 마이페이지 수정나 [x] 운동기록 페이지(차트 시각화) (+등록)나 [x] 구독 결제 페이지(카카오 결제)나 [x] 메인페이지 및 네비게이션바 [x] 트레이너 매칭페이지 [x] 트레이너 매칭페이지 등록 수정 삭제 [x] 트레이너 매칭페이지 디테일 팝업 [x] 트레이너 매칭페이지 결제(카카오 페이) [x] 커뮤니티 페이지 [x] 커뮤니티 페이지 등록 [] 커뮤니티 페이지 수정 삭제 [] 커뮤니티 페이지 좋아요

https://velog.velcdn.com/images/k_gi/post/750e093c-5978-46a0-82da-993ec4c71574/image.pdf

프로젝트 회고

첫 미팅부터 PM으로써 열심히 기획하고 (하루 5시간 회의) 프론트엔드 백엔드 팀원에게 페이지마다 설명하면서 이해시키고, 열심히 3주동안 달렸던 거 같다. 일단 기획한 부분에 100% 완성은 하지 못했지만, 어느정도 괜찮은 작품이 나온 거 같아 뿌듯했다. 일단, 기획회의에서 욕심을 부렸던 나머지 페이지 숫자가 많이 나왔고, 팀원들의 역량을 파악해 페이지를 줄였지만 그 역시 과했던게 아쉬웠다. 나름 팀원의 상태를 파악하면서 회의도 주도적으로 했지만 잘 따라오지 못하는 팀원에게 하루종일 붙어있을 수 없던 노릇이라 조금 놓친 부분이 있었나보다. 그래도 2차 프로젝트보다 소통도 열심히하고, 나도 나름 열심히 불태운 프로젝트라고 생각이 들어서 한편으로 뿌듯하면서 조금 더 성장했다고 느낀다.

프로젝트 소개

우리 프로젝트를 통해서 도출하고자 한 웹 서비스

• 차에 관심이 적거나 입문하기 위한 고객을 위해 보다 쉽게 차에 대해 접근해 구매할 수 있는 웹 서비스를 구현하였다.

해당 웹 서비스가 시장에서, 사용자들에게 전달하는 제품적 가치와 의미

• 차에 대해서 입문하고 싶거나, 접근이 어려웠던 사람들을 위해 랜덤 티 구독 서비스 제품을 판매하여 다양한 차를 소량껏 접해보고, 입문할 수 있게 설계하였다. 커피나, 음료에 익숙한 현대인에게 소소한 재미를 주고, 차에 대한 즐거움을 선물하는 의미를 가지고 있다.

해당 웹 서비스를 개발하기 위해 소요된 모든 시스템 설계 (디자인) 도면, Workflow, 고민사항 등

• 차에 대한 서비스인 만큼 페이지의 색상이 다채롭지 않고 녹색 계열의 색상을 사용하였으며, 차 입문자들을 위해 차 이미지에 신경써서 디자인 도면을 그렸다. 또한 차에 관심이 있는 연령대가 높은 만큼 버튼의 크기를 크게 설계했다.

기술적으로 구현해 낸 실제 웹 페이지 모습 (각 페이지 별, 데이터 별 요소들의 기획 배경)

• 이미지에 어느정도 중점을 둔 서비스라 이미지에 마우스를 오버했을 시 그 제품의 다른 이미지를 보여주며 작은 화면에서 보다 많은 이미지를 표출하였고, 제품페이지 , 제품 상세페이지 등 거의 모든 페이지에 나타나는 이미지를 중점으로 기능을 부여했다.

팀원간 효과적으로 소통하여 이루어낸 업무의 능률적인 개선 프로세스

• aws를 통해 프론트엔드와 백엔드의 테스트가 보다 쉽고 원할하게 진행이 되었다.

스스로 짚어보는 해당 웹 서비스의 아쉬운점 그리고 개선점

• 소통 부족과 일정관리로 인한 원하는 기능들을 추가로 구현하지 못한 부분이 아쉽다.

내 역할

• ProductManager
• 메인페이지, 네비게이션바
• 제품 리스트페이지
• 제품 상세 페이지 및 리뷰리스트
• 장바구니 추가 및 장바구니 상세 페이지
• TRBOX페이지

checkList

FrontEnd - TODO

• 마이페이지 회원 정보 통신
• 기본배송지 삭제
• 기본배송지 수정
• 상품 구매 페이지 UI
• 상품 구매 페이지 통신
• 추가) 마이페이지 주문내역 통신
• 추가) 선물하기
• 마이페이지 배송지 추가
• 마이페이지 통신
• BEST상품 페이지 통신
• BEST상품 리스트 SORT
• 장바구니 삭제 나
• 장바구니 페이지 통신 나
• 장바구니 수정 나
• 장바구니 추가 나
• 추가) TRBOX 나
• Footer 구현 나
• 장바구니 페이지 UI 나
• 페이지네이션 컴포넌트 나
• 리뷰 컴포넌트 나
• 제품 상세제품 장바구니 페이지로 나
• 제품 상세제품 구매 페이지로 나
• 제품 상세 페이지 통신 나
• 제품 상세 페이지 UI 나
• 제품 리스트 페이지 통신 나
• 제품 리스트 SORT 나
• 제품 리스트 페이지 UI 나
• NAV바 장바구니 통신 나
• NAV바 UI 나
• 메인페이지 BEST상품 장바구니 추가 나
• 메인페이지 BEST상품 통신 나
• 메인페이지 UI 나
• 마이페이지 UI 완료
• BEST상품 리스트 페이지 UI 완료
• 이미지 베너(메인페이지)생성 완료
• 칩 컴포넌트 생성 완료
• 탭 컴포넌트 생성 완료
• 인풋 컴포넌트 생성 완료
• 아이콘 버튼 컴포넌트 생성 완료
• 버튼 컴포넌트 생성 완료
• 회원가입 통신 완료
• 회원가입 벨류데이션 체크 완료
• 회원가입 UI 완료
• 로그인 통신 완료
• 로그인 벨류데이션 체크 완료
• 로그인 UI 완료

https://velog.velcdn.com/images/k_gi/post/d0d0c480-7a32-4bcc-94d4-3e844f41cad3/image.pdf

프로젝트 회고

일단 아쉬움이 너무 많이 남는 프로젝트였다. 초반에는 다른 팀보다 프론트엔드 팀원이 적어서 서로 열심히 하자는 마음으로 달려들었지만 첫번째 문제는 팀원이 두명이다 보니 한명이 부득이하게(추석) 일정이 있을 때 머지를 못해줬다. 브렌치가 하나면 상관이 없었지만 서로 영향을 주는 페이지로 브렌치를 따로 파게 되다보니 꼬일 때가 있었는데 빨리 머지를 받고 싶었지만 그럴 수 없는 상황이 생겼고, 또한 서로의 의견차이 때문에 일정도 늦어진 감이 있다. 내 의견은 '굳이 버튼을 컴포넌트화 할 필요 없다.' 였고, 다른 팀원은 리엑트를 배웠으니 컴포넌트화를 하자였다. 나는 거의 모든 페이지에서 버튼의 크기와 색상이 달라서 공통되는게 없다는 판단으로 그런 의견을 냈다. 아무튼 의견 충돌이 있었지만 다른 팀원의 의견대로 컴포넌트화를 했고, 그로인해 시간이 늦어진게 아닌가 싶다.(css로 해도 충분하지 않았을까..?) 또한 추석에 통신을 기다리면서도 너무 답답했다. 백엔드와 DB서버가 각자 로컬에 있어서 같은 공간에서 각자의 ip로 테스트 해야했고, 로그인과 장바구니 페이지가 다른 사람일 경우, DB도 서로 맞춰놔야 했지만 아직 준비가 되지 않아서 맞춰보기 힘들었다. 처음부터 적어도 DB서버를 하나로 통합했다면 진행이 조금 더 매끄럽지 않았을까..? 라는 생각을 해본다.

• 3차 프로젝트 시작
  • 마이페이지 UI완료
  • 멘토리뷰 반영

2023/10/10(화)

• 3차 프로젝트 진행
  • 로그인 회원가입 후 상세로그인 api 구현 테스트 완료
  • 멘토리뷰 반영

2023/10/10(수)

• 3차 프로젝트 진행
  • 회원 정보 수정 UI완료
  • 멘토리뷰 반영

2023/10/10(목)

• 3차 프로젝트 진행
  • 운동기록 페이지 UI 완료
  • 멘토리뷰 반영

2023/10/10(금)

• 3차 프로젝트 진행
  • 각 페이지 기능 정리 및 멘토리뷰 반영

한 주 마무리

프로젝트 회고

6일차

• 주말에 따로 프로젝트 코딩을 하지 않고 평일에 하루 한 페이지씩 UI와 api 연결 직전 로직만 짜 놓으면 어느 정도 일정은 맞을 거라는 생각에 마이페이지 코딩에 들어갔다. 매일 한 번씩 push를 하고 멘토님이 리뷰를 달아주고 리뷰에 나온 수정사항을 반영하고 머지되는 일정으로 아마 이번 주는 흘러가지 않을까 싶다.

7일차

• 카카오 간편 로그인 api 후 신규 유저는 상세 정보를 입력하도록 하게 페이지를 이동시키고, 그 정보를 DB에 저장해야 했다. 여기서 문제는 로그인 후 신규 유저는 유저의 ID(테이블의 PK)가 프런트엔드에서 가지고 있다가 정보를 작성 후에 ID를 같이 넘겨줘야 했고, 그래서 usenNavigate를 통해 state에 저장 후 이동하려 했지만 곰곰이 생각해 보니 화면상에 회원의 PK가 있으면 안 될 거 같았고, token 키를 발급받아 사용하려 했지만 로컬 스토리지에 accessToken을 발급해 주면 신규 유저가 상세 정보를 입력하지 않고 페이지를 나간 후 재접속을 했을 때, 이미 로그인 된 회원이지만 정보가 없어 화면상에서 오류가 날 거 같았다. 그래서 NewUser라는 Token을 새로 발급해서 상세 정보를 입력 후 DB에 저장이 되었을 때 NewUser라는 Token을 지워줬다.

8일차

• 회원정보를 수정하는 페이지에서 회원의 이미지를 수정하는 로직이 있어야 했고(카카오 프로필 이미지를 사용하기 때문) 나는 파일 첨부가 어렵다고 판단했지만 프런트엔드에서는 딱히 해줄 로직이 별로 없었다(파일을 받아 백엔드에 전달 + state에 가지고 있다가 미리 보기 표출)

9일차

• 운동 기록 페이지에 UI를 목데이터를 가지고 완성했다. 전에 다니던 회사에서 쓰던 차트 라이브러리(amchart)를 사용했고, 너무 익숙해서 금방 차트가 5개가 나왔다. 전에 회사에서도 차트를 공통 함수를 이용해서 짧게 쓰려고 했었고, 이번에도 라인 차트 함수 하나를 가지고 4개의 차트를 표출했다(색상, 아이콘, 단위 등 다르게 표출)

10일차

• 프로젝트가 일주일도 남지 않은 상태에서 팀원들의 상태를 점검해 봤는데 일정이 널널할 줄 알았는데 생각보다 팀원들이 뒤쳐져있었다. PM으로써 첫 회의 때, 페이지를 구상하는 과정에서 팀원들의 역량에 맞게 페이지를 나눴고, 어느 정도 작업량을 줄였다고 생각했지만 잘못 생각했던 거 같다. 그래서 나는 어느정도 UI와 가능이 나왔기 때문에 다음 주에는 백엔드와 api를 맞춰보고 나머지 시간은 팀원(프론트)들을 케어하는 방향으로 가야겠다.

• Producting 강의 (10시30분 ~)
• 3차 프로젝트 시작
  • 시나리오 선정 회의

2023/10/10(화)

• 3차 프로젝트 진행(PM)
  • 화면 UI별 기능 요구 정의( 총 13페이지 )
  • 디자인 테마 선택

2023/10/10(수)

• 3차 프로젝트 진행
  • ERD회의 참여
  • UI 설계 회의 및 도면 그리기

2023/10/10(목)

• 3차 프로젝트 진행
  • 로그인 회원가입 (카카오, 네이버 API) 구현 테스트

2023/10/10(금)

• 3차 프로젝트 진행
  • 상세 회원가입 UI 완료

한 주 마무리

프로젝트 회고

1일차

• 2차 프로젝트가 끝나고 주말 휴식시간이 주어지고 바로 3차 프로젝트를 시작했다. 팀원이 결정되고, 어떤 프로젝트를 할 것 인지 주어진 4개의 시나리오에서 회의 끝에 헬스케어 홈페이지를 선택했다. 이유는 다른 프로젝트에 비해서 아이디어가 많이 나올 거 같았고, 프론트와 백엔드에 비율이 그나마 괜찮을 거 같아서다. 백엔드에 비해 프론트의 숫자가 2명이 적은 만큼 프론트엔드에 무리가 가지 않을 사이트와 팀원 각자의 실력 편차가 나는 만큼 모두 같이 만들 수 있는 주제가 좋을 거 같다는 생각이었다.(지도가 들어가면 메인이 지도고, 그 파트 인원한테만 무리가 갈 듯) 그리고 이번에도 PM을 맡아서 회의를 주도했다.

2일차

• 칠판에 우리가 구현 할 페이지의 구성을 그리면서 어떤 기능들이 들어가면 좋을지 회의를 했다. 회의 시간만 5~6시간이 걸린 만큼 말도 많이하고 많은 의견이 오갔고, 의견들을 종합해서 페이지를 결정했다. 이런 회의를 주도한 이유는 프론트엔드는 당연히 화면 구성을 알아야하며, 백엔드 또한 화면 구성을 알아야 어떤 API가 필요한지 어떤 API를 어떻게 짜야하는지 알 거 같아서기 때문이다. 아무튼 회의끝에 많은 양의 페이지가 나왔고, 일정과 인원분배 및 실력편차 등을 고려해 13페이지를 하기로 결정하고 나머지 페이지는 추가구현사항으로 하기로 결정했다.

3일차

• 백엔드는 ERD 회의를하고, 프론트엔드는 UI설계를 하기로 했다. 나는 백엔드에 어느정도 지식이 있었고, DB테이블 설계도 어느정도 해본 만큼(전 회사) ERD회의에 참여해서 같이 ERD를 그렸고, 곧바로 프론트엔드 UI설계 및 도면 그리는 작업에도 참여해 피드백을 해줬다. 3일동안 회의지옥에 빠졌더니 시간이 너무 빨리 지나갔다.

4일차

• 팀원이 figma를 통해 UI를 그릴동안 다른팀 백엔드와 네이버, 카카오 간편 회원가입을 맞춰보고 프로젝트 초기 세팅 후 간단한 UI를 구현했다. 우리 프로젝트 로고와, 간편회원가입 버튼만 들어간 페이지라서 UI설계가 나오기 전에도 만들 수 있는 간단한 페이지라서 먼저 개발작업에 들어갔다.

5일차

• 초기세팅과 회원가입 branch를 push했는데 멘토님이 리뷰를 달아줬다. import순서나 css등 자잘한 수정사항이 나와서 수정 후 머지를 기다렸지만 멘토님도 다른 팀의 merge내용을 리뷰하느라 속도가 안나서 새로운 브렌치를 하나 생성해 상세 회원가입 UI를 만들었다.

• 2차 프로젝트 진행
  • 페이징 처리 완료 및 제품 상세 구현 완료
  • 제품 상세 및 제품 BackEnd통신 완료
  • 장바구니 UI 완료

2023/10/03(화)

• 개천철
  • trbox UI(차 구독 서비스) 완료

2023/10/04(수)

• 2차 프로젝트 진행
  • 장바구니 api연결
  • footer UI 완료
• AWS 강의(17시~18시) ⭐️

2023/10/04(목)

• 2차 프로젝트 진행
  • 장바구니 api연결 (갯수 증감, 장바구니에 제품 금액 계산, 장바구니 삭제) 완료

2023/10/05(금)

• 2차 프로젝트 진행
  • 발표 준비 PPT 제작 및 프로젝트 완료

2차 프로젝트 git URL : https://github.com/wecode-bootcamp-korea/49-2nd-TeaTime-frontend

한 주 마무리

프로젝트 회고

6일차

• 추석이 있어서 1주일간 각자 코딩을 하느라 서로의 진도를 알 수 없어서 서로 진도를 확인하면서 통신도 맞춰봤다. 제품에 관한 연결은 무난하게 완료 했지만 내가 맡은 장바구니는 로그인이 구현이 되고, 로그인을 구현한 백엔드 팀원과 장바구니를 구현한 백엔드 팀원이 테이블에 데이터가 같아야하고, 소스가 현상관리가 잘 되어있어야 하는데 각자 맡고있는 진도를 빼기 바쁘고 DB도 통합되지 않아서 백엔드 팀원들이 우왕좌왕하는 모습이 보였다. 그래서 백엔드 팀원에게 통합DB가 있고, 소스를 한명이 통합으로 관리되어야 될 거 같다고 했고, 멘토님에게도 따로 물어봐서 이런 팀 프로젝트에서 DB도 소스도 다 다르니깐 프론트엔드에서 테스트를 해보고 싶어도 할 수 없다고 얘기했고, 답변도 똑같이 DB를 통합으로 관리해야한다고 말씀해주셨다. 그래서 백엔드에서 DB와 소스를 서버에 올려서 관리하기로 하였다. 내일도 빨간날이라 각자 코딩해야하지만 앞으로는 서버에 올라가 있는 백엔드와 통신이 가능해서 편리해졌다. 현업에서는 물론 회사 서버에서 DB나 소스형상관리나 구동되는 개발서버가 있어서 바로바로 테스트 할 수 있지만 추석기간과 빨간날에 테스트를 해 보고 싶어도 할 수 없어서 너무 답답했다.

7일차

• (개천절) UI가 완료된 페이지에 api연결 테스트를 할 수 없어서 추가로 구현하기로 한 구독서비스 UI를 만들었다. 백엔드와 프론트엔드의 연결문제로 인한 일정이 관리가 잘 안되는 것에 대한 벽을 느꼈다.

8일차

• 장바구니 api를 연결하기로 한 날이지만 백엔드 팀원이 완성을 못한 관계로 테스트는 못하고 부족한 UI 부분을 수정하였다.

9일차

• 프로젝트 완료일자 하루전에 백엔드와 연결테스트를 하고, 리턴받은 결과값을 화면에 뿌려주고 이벤트를 구현했다. 하루만에 하려니 시간이 빠듯했지만 어느정도 로직을 머리로 생각하면서 함수를 작성해놔서 빠른 시간안에 완성했고, 2주(추석 주까지 3주)동안 내가 구현하고자 하는 페이지는 모두 구현했다.

기술적으로 아쉬웠던 점

1. 네비게이션에 있는 장바구니 갯수 -> 가져오려면 새로고침밖에
2. fetch문 2번 돌리는거 속도 너무 느림.

react-router-dom에서 동적 라우팅을 구현하는 방법은 Route 컴포넌트의 path prop에 : 기호를 활용하는 것이다. 경로/:문자열형태로 path를 설정하면 URL에서 경로/ 뒤에 무슨 글자가 오든 이 Route로 연결되게 된다.

Path Parameter

• useParams hook

import { useParams } from "react-router-dom";
const params = useParams();

을 사용해서 url뒤에 붙은 파라미터를 가져 올 수 있다.
(상세페이지에서 사용하면 좋음)

## 쿼리 스트링

구체적으로 요청을 하기위함

### 쿼리 스트링의 형태
 - 쿼리 스트링은 이름 그대로 문자열의 형태를 띠고 있으며 key=value로 표현
 - URL에서 쿼리 스트링이 시작된다는 표시는 `?` 문자를 통해서 표현
- 쿼리 스트링 내에서 각각의 `key=value` 페어를 구분할 때는 `&` 문자를 사용
 - react-router-dom에서 쿼리 스트링을 활용하기 위해서 사전에 Router 컴포넌트에 특별한 설정을 할 필요는 없다.

### 컴포넌트에서 쿼리 스트링 값 가져오기

react-router-dom에서 쿼리 스트링을 가져올 때 사용할 수 있는 hook은 useLocation, useSearchParams 두 가지가 있다.

 - useLocation hook

>  const location = useLocation(); //url 전체 가져오기
const queryString = location.search; // url 중 쿼리스트링 부분만 가져오기

전체 쿼리 스트링을 하나의 문자열 형태(?sort=popular)로 표현해 주기에 이 중에서 원하는 값만 가져오려면 저 문자열을 자바스크립트를 통해서 Parsing 하는 과정을 거쳐야 한다.


 -  useSearchParams hook
   1.  값을 읽어오는 메서드
>  const [searchParams, setSearchParams] = useSearchParams(); //쿼리스트링에 key:value로 세팅
searchParams.get(key); //key값으로 value가져오기




2.  값을 변경하는 메서드

> searchParams.set(key, value) // 쿼리스트링 세팅하는 함수(기존 값 변경)
searchParams.append(key, value) // 기존의 값을 변경하거나 삭제하지 않고 추가하는 방식
-> 후 setSearchParams(searchParams)

searchParams를 변경하는 메서드를 이용해서 searchParams의 값을 변경하더라도 실제 URL의 쿼리 스트링은 변경되지 않습니다. 변경된 searchParams를 이용해서 실제 쿼리 스트링을 변경시키려면 setSearchParams 함수에 searchParams를 인자로 전달하면서 호출해야 한다.


쿼리 스티링 방법은 페이징처리, 정렬처리에 유용하다.

- 위코드에 들어온 이유

위코드에 오기 전 나는 gis플랫폼을 개발하는 개발팀에서 2년 4개월 동안 개발을 해왔다. 내가 회사 생활을 하는 동안 우리 회사는 각 지자체를 타겟으로 삼았고 전자정부 프레임워크를 기반으로 개발을 해왔다. 전자정부 프레임워크에서 보안상의 이유로 react, vue, node를 사용할 수 없다고 들었고 물론 직급이 제일 낮은 사원이 여태껏 잘 돌아가던 java와 javascript를 사용하던 프로젝트들 갈아엎을 수 없었고 또한 프로젝트 기간이 촉박해서 다른 시도를 해 볼 시간이 없었다. 회사 생활을 하던 동안에도 다른 기술을 시간을 가지고 공부하고 싶었고, 퇴사 후 취업에도 도움이 되고 공부도 하고 비슷한 나이대 사람들과 프로젝트를 할 수 있는 부트 캠프를 찾아보고 위코드를 선택하게 되었다.

- 위코드에서 첫걸음 ( Pre-course )

위코드를 본격적으로 시작하기 전에 2주 동안 javascript, css, html을 기초적으로 매일 2~3시간씩 줌 수업을 통해서 온라인으로 진행되었다. 지금껏 개발을 해왔지만 실무에 맞게 개발을 하다 보니 기초적인 부분에 있어서 까먹고 있거나, 이유도 모르고 쓰고 있던 것들이 있어서 알고 있는 내용이라도 기초를 천천히 다시 다져보는 시간을 가졌다. 그래도 개발 경력이 있다 보니 수업은 잘 따라가졌다.

- 본격적인 오프라인(Foundation)

주말을 제외하고 매일 동안 프론트와 백엔드를 나눠서 foundation이 진행되었다. 프론트엔드 세션에서는 React에 대해서 배웠고(배운 내용은 기술 블로그에 정리해놓았다.) 공통세션에서는 서버, DataBase, 개발자로써 필요한 마음가짐등 수업이 진행되었다. 아침부터 저녁까지 세션이 진행되지는 않았지만 세션이 끝난 시간은 공유오피스를 사용해서 팀원(foundtion팀-프론트엔드 인원끼리)과 함께 과제도 진행하고 각자 필요한 부분을 학습했다. 학습 과정에서 나는 어느 정도 경험으로 이해할 수 있는 내용이 많았고 팀원들은 그런 나에게 많이 질문했다. 답을 해주는 과정에서 나도 배워가거나 다시 한번 정리하는 과정을 가지면서 나에게도 또한 팀원에게도 많이 유익했던 시간이었다.

- 첫 프로젝트 (Weread)

부트캠프의 꽃이라고 불리는 팀 프로젝트 시간이 다가왔다. 지금까지 배워왔던 기술들을 활용해서 UI를 그리고, 함수를 사용해서 버튼등 컴포넌트를 제어 한 뒤 원하는 정보를 가지고 백엔드와 통신을 하면 되는 가장 중요하면서 간단한 회원가입창을 만들고, 게시물을 가져오는 프로젝트였다. 일단 팀원들은 완벽할 정도로 좋은 팀원이고 실력적으로도 뛰어난 팀원들이 다 모여서 프로젝트의 기본적인 기능들은 기한내에 완성하고 추가기능까지 개발 하는 것에 욕심이 난 나머지 일정을 빠듯하게 가져갔다. 하지만 첫 프로젝트인 만큼 소통이 원할하지 못했고, 작은 마찰도 있어 결국 추가기능은 원하는 만큼의 절반정도 밖에 해내지 못했다. 백엔드는 백엔드 따로 기능별 파트를 나누고 프론트엔드는 나와 팀원이 합의하에 나는 회원가입, 게시물 가져오기, 글 쓰기, 상세페이지, 글 삭제, 글 수정 기능을 맡아서 구현을 했고, 같은 팀원은 로그인, 댓글가져오기, 댓글 삭제, 댓글 수정, 댓글 작성을 하기로 했다.

- 1차 프로젝트 회고 (내가 부족했던 점)

일단 짧은 기간에 다른 팀보다 잘하고 싶었던 마음에 일정을 빡빡하게 가져가고, 소통이 적었던게 문제가 있었던 것 같다. 백엔드와 소통이 부족해서 통신하는데 하루를 썼으니 다른 기능을 구현하는데 시간이 부족했다. 그리고 팀원의 역량을 제대로 체크하지 못하고 다 할 수 있겠지 라는 마음이 팀원의 마음을 조급하게 만들었을지도… 아무튼 필수 구현 사항은 잘 마무리 해서 다행이지만 나도 나대로 완벽하지 못한 소스코드를 작성했다는 실망감과(코드리뷰에서 지적이 나왔던 간결하지 못하고 긴 나의 소스) 자만이 이번 프로젝트에서 아쉬운 부분이다. 좋았던 부분은 같은 팀 프론트엔드 팀원보다 개발지식이 조금 더 있어서 많은 부분 도움을 주고, 기간안에 못끝낸 부분은 내가 같이 해결해서 생각했던 것 보다 완벽하게 완성한 거 같아서 뿌듯하다. 그리고 팀원이 프로젝트 중에 궁금한점을 질문하고 그 질문에 고민하고 대답해주는 과정 속에서 나도 많은 것을 배우고 복습했다.

https://velog.velcdn.com/images/k_gi/post/e5cac2e7-0fae-47d2-a565-32591d191a03/image.mp4

• 2차 프로젝트 진행
  • 팀 배치 완료
  • 프로젝트 주제 선정 완료
  • PET 분석 제품, end-user, tech 정리 완료
  • 구현 기능 선정 완료
  • 프로젝트 환경설정 완료

2023/09/19(화)

• RESTful API 강의 (Advanced Router 강의와 비슷 전체 세션)
• 2차 프로젝트 진행
  • 시나리오 작성 (api 설계 및 구현 순서 정하기 위해)
  • 각 페이지 별 컴포넌트 분리하기

2023/09/20(수)

• 2차 프로젝트 진행
  • 페이지 담당 정하기
  • Nav UI 완료
  • Main UI 완료

2023/09/21(목)

• Advanced Router 강의
  • 2차 프로젝트 진행

    - 제품 리스트 UI 완료

2023/09/22(금)

• 2차 프로젝트 진행
  • 페이징 처리 완료 및 제품 상세 구현 중

한 주 마무리

프로젝트 회고

1일차

• 2차 프로젝트가 시작하고 팀 발표가 완료됐다. 다른 팀들은 프론트엔드 3명, 백엔드 4명인데 우리팀만 프론트엔드가 2명이라서 멘붕이 왔다. 프로젝트 주제가 정해져 있지만 어디서부터 어떻게 해야할 지 갈피가 잡히지 않고 2명이 해낼 수 있을까 라는 불안감이 생긴다. 아무튼 주제는 오설록으로 정했다. 타겟층이 확실하고 깔끔한 디자인과 차(tea)라는 카테고리에 맞게 차분하고 고급진 디자인이 마음에 들어서 선택하게 되었다. 어느 기능까지 기한 안에 할 수 있을지 팀원과 상의해서 기본적인 기능(로그인/회원가입, 제품리스트/상세리스트, 제품 주문)까지는 구현해보자고 하였다. 또, PET 분석으로 우리가 구현할 사이트의 판매 제품은 무엇이고 누굴 타겟으로 하고 있으며 어떤 기능을 구현하고 있는지 분석했다.

2일차

• 백엔드 erd 그리는 회의에 같이 참가했다. 프론트에서 받아야 하는 데이터가 있고, 어떤 데이터들을 관리하는지 듣고 싶어서 백엔드 회의에 참여했다. 팀원들도 아직 개발에 익숙하지 않을 뿐더러 데이터를 테이블적인 관점에서 분석하는게 서툴어서 ‘프론트에서는 이런 데이터가 필요해서 테이블에서 관리 할 필요가 있다.’라고 힌트를 주면서 테이블 설계를 도와주었다.

3일차

• 각 담당 페이지를 나누고 각 페이지별 기능과 컴포넌트를 나누는 회의를 진행하고 바로 Nav바와 Main페이지를 진행하였다. 2주라는 시간안에 가능할 지 모르겠지만 최선을 다해서 중요한 기능은 최대한 완료하는 쪽으로 진행하기로 하였다

4일차

• 아침 회의에서 테이블 설계때 놓친 부분을 백엔드와 의논해서 추가 및 삭제를 진행하고 제품의 리스트 부분 UI를 개발하였다. 페이지를 나눌 때 최대한 완벽하게 진행하기 위해서 내가 맡은 부분이 중요한 부분이 많았지만 다시 회의한 끝에 같은 팀원도 개발이 늦더라도 천천히 중요한 부분을 해보는 것이 좋지 않을까 라는 생각에 다시 페이지 분담을 새로 정하였다.

5일차

• 페이징 처리를 어떻게 구현해야 좋을 지 많은 서칭과 고민 끝에 구현을 끝냈다. 각자 다른 개발 방법, 또는 라이브러리를 사용해서 개발했지만 일단 백엔드에서 프론트의 비중을 줄여주기 위해(우리 팀은 프론트가 다른팀보다 숫자가 적고 백엔드가 4명이다.) 페이지에 보여주는 리스트를 계산해서 보내주겠다고 해서 구글링에서 나온 방법과는 조금 다르게 개발 해야 한다는 것을 깨닫고 노트에 적어가며 구현해냈다.

• Planning Meeting (10시 ~ 12시)
• Portfolio - 과정중심 사고기법(강의) (12시 ~ 13시)
• 1차 프로젝트(weread) 시작
  • 저번 주말 작업 => UI 적용 (모든 페이지)
  • 초기 세팅 및 페이지 css 보충 수정
  • 회원 가입 시 중복 확인(이메일, 닉네임) 후 disabled처리와 비밀번호, 비밀번호 확인 input이 같으면 회원가입 버튼 활성화

2023/09/12(화)

• Planning Meeting (10시 ~ 10시30분)
• 컴포넌트 재사용(강의) (10시30분 ~ 12시)
• 1차 프로젝트
  • 로그인 테스트 완료
  • 글 목록 가져오기 (Mock데이터로 가져오기는 완료) -> backend와 테스트 필요
  • 회원가입 테스트 완료
  • 회원가입 : 각 컴포넌트의 값을 state로 관리, 전화번호는 객체로 (국제번호+번호)관리 및 숫자길이, 3,4자리 수마다 - 붙여주는 정규식

2023/09/13(수)

• Planning Meeting (11시 ~ 11시30분)(with 멘토)
• 1차 프로젝트
  • 글 작성 테스트 완료
  • 글 목록에서 localStorage에 있는 아이디 값이 같은 글만 삭제 수정 버튼 보이게

2023/09/14(목)

• 1차 프로젝트
  • 글 목록(backend)와 연결 테스트 및 목록 가져오기 완료
  • 글 쓰기 완료
  • 글 상세페이지 완료
  • 글 삭제 완료

2023/09/15(금)

• 1차 프로젝트
  • 댓글 수정 및 삭제 완료
  • 프로젝트 마무리 및 회고
• 개발자의 회고록 작성법 강의(15시 ~ 16시30분)
  • 개발을 왜 하게 되었는지
  • 이번 프로젝트 기간에 대해서
• Product + ing(16시 ~ 18시)
  • Product(제품 관점) : 제품을 고객의 관점, 제품의 목적, 제품을 개발자의 관점, 제품의 매출발생 원리
  • End-user (사용자 관점):사용자가 왜 우리제품을 사용하고 있는지, 사용자의 동선 파악(제품속에서)
  • Tech (기술 관점) : 사용하고있는 기술스택과 버전, 회사의 비즈니스 로직, 기획과 설계에 대해서, 기술구현이 효율적으로 구현되었는가, 코드의 확장성과 유지보수성, 프로그래밍 전략

한 주 마무리

프로젝트 회고

1일차 - 내 성격 자체가 간당간당한 일정을 싫어하는 탓에 주말에 UI를 다 그려놨다. 필수 구현 요소보다 더 많은 요소를 구현하고 싶은 마음에 조급해 졌나 보다..

2일차 - 백엔드와 통신이 늦어져서 글 목록 페이지를 mock데이터를 사용하여 불러왔다. 아직까지는 강의에서 배운 내용을 사용하기 때문에 어려움은 없었지만 같은 팀원 프론트엔드분께서 selectBox를 동적으로 가져오는 부분에서 state를 사용하지 않고 가져와서 혼자서 다시 코드를 짜기보다는 팀원이 짜놓은 로직을 사용하는 방향으로 문제를 해결했다. (아직은 서로 배우고, 각자 파트가 정해져 있으므로 침범하지 않으려 했다.)(selectbox에 onchange를 사용해서 value 값을 가져오는 부분에서 value 값은 가져오는데 select 박스가 바뀌지 않는 문제였다. 그래서 onchange를 없애고 회원가입 버튼을 눌렀을 때, id 값을 통해서 value를 가져오는 방향으로 진행하였다.)

3일차 - 오늘 일정이 게시글쓰기, 게시글 목록 불러오기를 완료하는 줄 알았으나 백엔드 담당 팀원이 로직만 완성하고 먼저 집에 가서 남은 다른 팀원과 맞춰보는 중 더 필요한 로직이 필요해서 백엔드 코드를 수정하여 사용했는데 팀원과 상의 없이 수정한 행동으로 인하여 약간의 트러블이 있었다. 아마도 소통의 부족이 원인이었던 거 같다. 프론트엔드와 백엔드가 나눠져 있다 보니깐 프론트는 프론트끼리 소통하는 경우가 많았지만 앞으로는 더 많은 소통으로 이런 일이 발생하지 않도록 해야겠다.

4일차 - 코드 리뷰시간에 멘토님의 피드백을 통해 내가 짠 코드가 실행하는데 문제는 없지만 더욱 더 간결화하고 짧게, 알아보기 쉽게 짤 수 있다는 것을 알았다. 코드를 간결화 하는 방법(es6 문법, 객체 구조분해 할당 등)을 기술블로그에 정리해봐야겠다.

5일차 - 생각했던 기능까지는 아니더라도 필수 구현사항에 몇 개의 추가 구현사항까지 완료하는데 성공했다. 다른 기능도 추가하고 싶었던 욕심이 있었지만 그래도 위코드에서의 첫 팀프로젝트는 나름 성공한 거 같아 뿌듯하다. 돌아보자면 어느정도 불화(?)도 있었고 부족한 부분도 있었지만 소스코드 상에서의 부족한 부분은 천천히 수정 해 나가면 될 거 같고, 팀원과의 불화는 어느정도 프로젝트를 진행하는 과정에서 생기는 소소한 부분이라고 생각한다. 주말에는 어느정도 나를 돌아보는 시간도 가져보고 내가 부족한 부분도 돌아봐야겠다.

주말동안 나를 돌아보고 다음주 2차 프로젝트는 보다 개선된 점으로 진행하길 바란다.

궁금했던 점

1. selectbox를 javascript에서 동적으로 만들고 관리 했을 시 , 재 rendering 될 때, 또 다시 동적으로 만들어서 select박스의 값을 바꿔도(on change) value는 바뀌어도 화면상에서 값이 바뀌진 않았다. 이유는 리렌더링 때문에 다시 selectbox를 그려주는 이유 때문인거 같은데 그렇다면 input에 글을 작성해도 onchange에 usestate를 사용하면 input박스도 재 렌더링 되면 값이 초기화 되야하는거 아닌가 …?

chatGPT : React는 Controlled Components 패턴을 통해 input 요소의 값을 React state와 동기화시키고, 가상 DOM을 사용하여 변경된 부분만 업데이트하여 이전 값이 유지됩니다. 이것이 React가 컴포넌트를 다시 렌더링할 때도 input 값이 초기화되지 않는 이유입니다.

• Controlled Components 패턴: Controlled Components 패턴은 React에서 input 요소의 값을 React state와 동기화시키는 방법이다. 이 패턴을 사용하면 input 요소의 값이 React state에 의해 제어된다. onChange 핸들러를 통해 input 요소의 값이 변경될 때마다 해당 값을 React state에 업데이트하면, 이 값을 다시 input 요소의 value 속성에 반영한다. 따라서 리렌더링이 발생해도 React는 항상 React state의 값을 input 요소에 설정하여 이전 값이 유지된다.
  • 가상 DOM (Virtual DOM): React는 가상 DOM을 사용하여 실제 DOM과 효율적으로 상호작용한다. 리렌더링이 발생하면 React는 가상 DOM을 사용하여 이전 실제 DOM과 비교하고 변경된 부분만 업데이트한다. 이것은 브라우저에 실제 DOM 업데이트를 최소화하고 성능을 향상시킨다. 그리고 Controlled Components 패턴을 사용하는 경우, React는 input 요소의 value 속성을 변경하면서 이전 값과 새 값 간의 차이를 가상 DOM에서 업데이트하게 된다. 이로써 이전 값이 유지되면서 리렌더링이 발생합니다.

2. 글 목록에서 삭제 시 데이터를 다시 불러오는게 맞는지(새로고침이나 fetch문을 다시 돌린다..?) 아니면 프론트엔드 자체에서 초기에 받은 데이터(state)에서 삭제하면 되는건지... A(멘토) : 개발자의 몫이다 ~ (무슨 방법이던 돌아가면 상관없다 단, 사용자의 편의를 고려해서)

• React Props & State (10시 ~ 12시)
  • hook 개념
  • props 개념
  • state 개념
• 개발자가 가져야 하는 마인드셋 (14시 ~ 15시)
  • 올바른 학습태도와 마인드셋이 중요
  • 자신만의 목표와 비전을 가지자
  • 좋은 관계를 형성하자 (개발은 결코 혼자하는 일이 아니다)
  • 내가 몸 담고있는 회사를 귀하게 여기는 마음
• CodeKata 가이드 (15시 ~ 15시30분)
  • Mon ~ Fri (20시 ~21시)
  • 매일 1시간씩 팀별로 알고리즘 문제를 풀어보는 시간

2023/09/04(화)

• Props & State 리뷰 (10시 ~ 11시30분)
  • … 문법 => 객체 복사 (객체 구조분해할당)
  • 객체 속 key값을 변수로 쓰려면 (대괄호) 사용
• useEffect 강의 ( 11시30분 ~ 13시 30분)
  • Side Effect
  • useEffect

2023/09/05(수)

• useEffect 리뷰 (10시 ~ 11시30분)
  • self check(test) 리뷰 (내 점수 : 100점)
• 인증 & 인가 (12시 ~ 13시)
  • Session & Token
  • Bcrypt
  • JWT
• Data 활용(14시 ~ 15시30분)
  • 상수데이터
  • Mock데이터

2023/09/06(목)

• Fetch 실습(11시 ~ 13시)
  • 로그인 회원가입 준비
  • fetch 함수 이론 및 실습
  • JWT
• 로그인 페이지 실습 (14시 ~ 17시)
  • front와 back이 하는 일
  • backend서버와 통신하기 실습
• Communication Skill의 중요성 (17시 ~ 18시)

2023/09/07(금)

• React Wrap up(10시 ~ 12시30분)
  • 이번주 react 수업 정리
  • 이벤트 위임 , 이벤트 캡처링, 이벤트 버블링
• 1차 프로젝트 준비 ( 14시 ~ )

한 주 마무리

Q1 : useState를 사용해서 state의 값을 업데이트 후 바로 console.log를 찍어보면 값이 바뀌지 않고 한 박자 느리게, 즉시 반영되지 않는다. 왤까… A: state강의 링크에 답 있음 ..

Q2 : fetch함수로 가져온 json데이터를 List형태로 가공하여 사용 할 때, 왜 usestate를 사용하여 setList를 해줘야 하는가.. 그냥 변수로 List를 선언하고 그 List에 값을 할당하면 안되는가 A (ChatGPT):React 컴포넌트에서 상태를 변경할 때 useState를 사용하는 것이 권장되는 이유는 React의 렌더링과 상태 업데이트 사이의 관계를 관리하기 위해서입니다. 직접 변수에 값을 할당하면 React는 이 변경을 감지하지 못하고 컴포넌트가 다시 렌더링되지 않습니다.

백엔드와 로그인 실습 때, 백엔드 오류가 나서 회사생활 하면서 익힌 백엔드 짬으로 해결 해 드렸다. 쿼리에서 user 테이블을 uesr로 오타가 난 것이었다. 3~4시간동안 해결 못했다는데 2년 넘게 개발하면서 스펠링 오타는 수도 없이 겪어봐서 … 뿌듯했다 …

서버에 HTTP 통신으로 요청(request)을 보내고, 정보를 응답(response) 받을 때 사용되는 메서드

비동기 통신이다. => 이전 작업의 종료 여부와 상관없이 기다리지 않고 다른 작업을 처리하는 방식

fetch 사용

// fetch 전문 예시

fetch("api주소", {               //1
  method:"...",                 //2
  headers: {"..."},             //3
  body:JSON.stringify({"..."})  //4
})                                            //요청
  .then((response) => response.json())   //5
  .then((data) => console.log(data))     //6
                                              //응답

1. 첫번째 인자(api주소) - 필수

2. 두번째 인자 (method) - 선택사항 (defult = GET) : 어떤 method로 요청할지 (GET, POST, PUT, PATCH, DELETE 등등)

3. 두번째 인자 (headers) - 선택사항 (서버에 요청할 때 보낼 부가적인 정보) : Host, user-Agent, Authorization, Content-Type 등등

4. 두번째 인자 (body) - 선택사항 (서버에 요청할 때 보낼 실질적인 정보) : JSON.stringify라는 메서드 사용 (서버에 보내는 데이터 형태를 맞춰줘야 하기 때문)

5. 첫번째 then

   .then(function onFullfilled, [function onRejected])
   ex) .then(res => res.json())

   서버에서 응답된 Json 형태의 데이터를 javascript객체로 변환해서 사용 가능하게 만들어 준다.

6. 두번째 then

   .then((result) => {
   alert(result) 
   }) 

   사용 가능한 데이터를 가지고 사용 될 함수를 작성한다.

정적인 데이터 Array.map() 메서드와 조합해서 반복되는 UI를 보다 간결하게 표현할 수 있다.

Array.map() 활용

for문, Array.forEach() 메서드와 유사하지만, 요소에 콜백 함수를 실행한 결과를 모은 새 배열을 return(반환)한다는 점에서 차이가 있다.

const arr = [1, 2, 3];

//코드를 줄이기 전
const newArr = arr.map(num => {
    return num * 2;
});

//위 코드를 줄이면 
const newArr = arr.map(num => num * 2);

상수 데이터 선언 위치

1. 컴포넌트 파일 내부에서 선언
2. 별도 파일로 분리

Mock Data란?

백엔드 API가 완성되지 않은 상황에서 개발을 진행해야 할 때, Mock(모조, 거짓) Data를 만들어 사용한다.

• 형태 : json 확장자 파일로 JSON 형식의 데이터를 생성
• 위치 : npm start 시 로컬 서버에 올라가는 폴더인 public 폴더 하위에서 관리
• 호출 : Mock Data는 실제 데이터와 동일하게 fetch 메서드에서 호출 우리가 생성한 Mock Data의 주소 입력, http://localhost:3000 은 생략이 가능하다.
  • 호출 시점 : useEffect hook을 통해 컴포넌트가 마운트(최초로 화면에 그려짐)된 후 한 번만 데이터를 받아오도록 한다.

누군가 또는 시스템이 실제로 그 누구인지 또는 시스템인지를 결정하는 과정

• SFA : 단일 요소 인증
• 2FA : 2개 요소 인증
• MFA : 다요소 인증

인가(Authorization)란?

사용자에게 특정 리소스 또는 기능에 대한 액세스 권한을 부여하는 프로세스

Session and Cookie

• Session : 동일한 클라이언트(사용자)가 브라우저를 통해 웹 서버에 접속한 시점으로부터 브라우저를 종료하여 연결을 끝내는 시점 동안에 들어오는 일련의 Request를 하나의 상태로 보고, 그 상태를 일정하게 유지하여 클라이언트와 웹 서버가 논리적으로 연결된 상태
• Cookie : 클라이언트의 컴퓨터에 저장되는 데이터 파일입니다. Cookie에는 이름, 값, 만료 날짜/시간(저장기간), 경로 정보 등으로 구성이 되어있다.

Session 기반 인증의 특징

• 장점 : 서버에서 정보를 관리하기 때문에 데이터의 손상 우려에 대해 상대적으로 안전 하다. 서버에서 상태를 유지하고 있으므로, 사용자의 로그인 여부 확인이 쉽고, 경우에 따라서 강제 로그아웃 등의 제재를 가할 수 있다.
  • 단점 : 모바일 기기와 브라우저에서 공동 사용 할 때 중복 로그인 처리가 되지 않는 문제 등 신경 써줘야 할 부분 들이 증가한다. 서버에서 모든 사용자의 상태를 관리해야 되므로 사용자의 수가 증가 할 수록 서버에 가해지는 부하가 증가한다.

• Token : 제한된 리소스에 대해 일정 기간 동안 접급 할 수 있는 권한을 캡슐화 한 것

Token 기반 인증의 특징

• 장점 : Token을 사용자 측에서 저장하므로 서버의 메모리나 DB 등의 부담이 없다. Token의 만료 시간을 짧게 설정하여 안정성을 높일 수 있다. 모바일과 브라우저의 멀티 환경에서 사용이 용이하다.
• 단점 : 서버에서 사용자의 상태를 저장하고 있지 않기 때문에 사용자의 로그인 여부 확인, 경우에 따른 강제 로그웃 등의 제재를 가하기 어렵다. XSS 공격에 취약하여 Payload에 민감한 정보를 포함하는 경우 위험할 수 있다. 사용자 식별을 위한 여러 정보들이 포함 되어 있어 Session Id의 길이보다 길어져 HTTP request 전송 데이터의 크기가 증가한다.

Bcrypt 란?

키(key) 방식의 대칭형 블록 암호에 기반을 둔 암호화 해시 함수 레인보우 테이블 공격을 방지하기 위해 솔팅과 키 스트레칭을 적용한 대표적인 예

• 솔팅(Salting) 단방향 해시 함수를 통해 암호화를 진행 할 때 본래 데이터에 추가적으로 랜덤한 데이터를 더하여 암호화를 진행하는 방식
• 키 스트레칭(Key Stretching) 단방향 해쉬값을 계산 한 후, 그 해쉬값을 또 다시 해시하고 또 이를 반복하는 방식

번역 : 부작용 또는 부수효과

함수의 부작용 이란 코드가 의도한 주된 효과 외에 추가적으로 발생하는 효과 ex) 함수의 목적인 Input을 받아서 output을 산출하는 것 이외의 모든 행위

• 외부의 상태를 읽어오기 함수 내부의 값이 아닌 외부의 값(변수, 함수, 객체 등등)을 읽어오는 행위
• 외부의 상태를 변경시키기 함수가 함수 내부에 있는 값이 아닌, 외부의 값(변수, 객체 등등)을 변경

프론트엔드에서 side Effect 사용 사례

Data Fetching, DOM 접근 및 조작, 구독 등의 행위가 있다.

useEffect

react에 함수컴포넌트 내에서 side Effect를 발생시키면 두 가지 문제가 발생한다.

1. side effect가 렌더링을 blocking 한다. 함수 컴포넌트의 return(html)이 보여지기 전에 side Effect동작이 실행된다.(사이트가 멈춰있다)
2. 매 렌더링마다 side effect가 수행된다. UI 업데이트가 발생할 때마다 매번 side Effect동작이 실행된다.

=>
1. 렌더링을 Blocking 하지 않기 위해서 **렌더링이 모두 다 완료되고 난 후 실행할 수 있어야 한다.**
2. 매 렌더링마다 실행되는 것이 아니라 **내가 원할 때만 조건부로 실행할 수 있어야 한다.**

useEffect 사용법

useEffect는 React에서 side effect를 편리하고 안전하게 발생시킬 수 있게 도와주는 hook이다.

import { useEffect } from 'react'

// 사용법
useEffect(콜백 함수, 의존성 배열);

// 1. 의존성 배열이 전달되지 않았으므로 ⭐️매 렌더링⭐️마다 side effect가 실행된다
useEffect(() => {
  // side effect
});

// 2. 첫 번째 렌더링 이후에 side effect를 실행하고
// 그 이후에는 ⭐️value 값이 변했을 때만⭐️ 실행한다.
useEffect(() => {
  // side effect
}, [value]);

// 3. 첫 번째 렌더링 이후에 side effect를 실행하고
// 그 이후에는 ⭐️value1, value2 중 하나라도 변하면⭐️ side effect를 실행한다.
useEffect(() => {
  // side effect
}, [value1, value2]);

//4.첫 번째 랜더링 이후에 side effect를 실행하고
// 그 이후에는 실행하지 않는다. 의존성배열은 선언했지만 값이 없기 때문
useEffect(() => {
  // data fetching side effect
}, []);

함수 컴포넌트의 렌더링과 useEffect가 발생하는 과정

1. 컴포넌트가 렌더링 된다. (최초로 진행되는 렌더링은 브라우저에 처음으로 이 컴포넌트가 보였다는 의미로 mount 라고 표현합니다.)

2. useEffect 첫 번째 인자로 넘겨준 콜백 함수가 호출된다. (Side Effect)

3. 컴포넌트의 state 또는 props가 변경되었을 경우 리렌더링이 발생한다. (update)

4. useEffect는 두 번째 인자에 들어있는 의존성 배열을 확인한다

   • a. 만약 의존성 배열이 전달되지 않았거나 / 의존성 배열 내부의 값 중 이전 렌더링과 비교했을 때 변경된 값이 하나라도 있다면 첫 번째 인자로 넘겨준 콜백 함수가 호출된다. (Side Effect)
   • b. 의존성 배열 내부의 값 중 이전 렌더링과 비교했을 때 변경된 값이 없다면 콜백 함수를 호출하지 않는다.
   • c. state 또는 props가 변경된다면 3~4의 과정을 반복

5. 컴포넌트가 더 이상 필요 없어지면 화면에서 사라진다.

   (컴포넌트가 브라우저의 화면에서 사라졌다는 의미로 unmount라고 표현합니다.)

Clean Up Effect

side Effect가 페이지 이동 후에도 계속 남아있다면 side effect를 clean up 해줘야 한다.

• Clean Up 방법 useEffect에 전달한 콜백 함수에서 clean up을 하는 함수를 리턴하면 된다.

클래스 컴포넌트에서만 사용할 수 있었던 state(상태) 관리와 lifecycle(라이프 사이클) 관리 기능을 함수 컴포넌트에서도 사용할 수 있도록 연동(hook in)해주는 함수 ex) useState, useEffect ..

규칙

• 함수 컴포넌트 내에서 호출 Hook은 클래스 컴포넌트 안에서는 동작하지 않으며 오로지 함수 컴포넌트 내에서만 사용해야 한다.
• 최상위에서 호출 해당 컴포넌트가 렌더링 될 때마다 항상 동일한 순서로 여러 개의 Hook이 호출되는 것을 보장할 수 있다. 또한 반복문, 조건문, 중첩된 함수 내에서는 Hook을 호출하면 안 된다.

Props란?

props란 컴포넌트의 속성값, 부모 컴포넌트로부터 전달받은 데이터를 지니고 있는 객체

사용법

• 부모 컴포넌트에서의 데이터 전달 tag에 속성을 주입하듯 자식 컴포넌트에 속성 값을 추가해 전달한다.

• 자식 컴포넌트에서의 전달 받은 데이터 적용 부모 컴포넌트가 전달해 준 props는 하나의 객체로 합쳐져서 함수 컴포넌트에 전달되고, props라는 이름으로 부모 컴포넌트가 전달해 준 값을 받아 사용하면 된다. ex)props.pet, props[”englishName”] 등..

• 함수 전달과 적용 위 방법과 같이 전달 받은 객체 속의 함수를 받아 사용하면 된다. ex)

  <button onClick={props.test}>클릭</button>

State란?

컴포넌트 내부에서 가지고 있는 컴포넌트의 상태값을 의미하며, 해당 컴포넌트가 UI에 보여줄 정보를 결정할 때 사용할 수 있는 상태값이다.

State 선언

useState 함수를 import한 후에 사용해야 한다. useState 함수는 Hook의 일종으로 내장되어 있는 react로부터 가져올 수 있다.

• const [state, setState function] = useState(defaultValue)
  • 첫 번째 요소(state)는 우리가 동적으로 관리하고자 하는 상태값입니다. 해당 상태의 초기값은 useState hook을 호출할 때 인자(defaultValue)로 넘겨줍니다.
  • 두 번째 요소(setState function)는 첫 번째 요소인 상태값을 업데이트 하는 함수입니다. state를 초기값에서 다른 값으로 변경하고 싶다면 setState를 통해서 변경해 주면 됩니다.

State 적용

defaultValue 있는 값은 변수명 state으로 사용 할 수 있다. 또한 setState function을 이용하여 상태값을 변경하면 할당 받은 state는 setState function함수로 바뀐 상태로 업데이트 된다.

** 과제 중 궁굼한 점** : useState를 사용해서 state의 값을 업데이트 후 바로 console.log를 찍어보면 값이 바뀌지 않고 한 박자 느리게, 즉시 반영되지 않는다. 그 이유는 useState는 비동기 처리로 반영 되기 때문에 값은 변해도 리렌더링을 통해 값을 다시 불러와야 한다고 한다. 따라서 이러한 경우 useefect를 사용하면 된다.

• Notion 공유 및 팀(조) 편성
• Frontend Kickoff (강의)
  • 현업 프론트엔드 개발자가 어떠한 업무를 하는지 파악할 수 있다.
  • 위코드 커리큘럼을 이해하고, 현업에 필요한 개발자가 지녀야할 마인드셋을 가질 수 있다.
  • React의 등장배경와 Web의 역사에 대해 알 수 있다.

2023/08/29(화)

• Linux 와 Terminal 강의 (10시30분 ~ 12시)
  • 운영체제란
  • Kernel & Shell
  • 리눅스의 파일 구조 (절대경로, 상대경로)
  • 환경변수 PATH
  • config file
  • 리눅스 명령어
• 개발자 기술 blog의 중요성 강의 (12시 ~ 12시30분)
• Database 강의 (14시 ~ )
  • 데이터베이스 기본 개념
  • 관계형 데이터 베이스(RDBMS)
• Database 실습
  • ERD 그리는 법
  • 스타벅스 사이트에 데이터 ERD 그리기 실습

2023/08/30(수)

• Git & Github 강의 ( 10시 ~12시30분 )(keyNote참조)
  • git과 github의 개념
  • git 명령어
• React Intro 강의 (14시 ~ 15시30분 )
  • React 개념 및 특징 (JSX)
  • node.js
  • CRA
• 지금 필요한 개발자 (COO 강의)(17시 ~ 18시)

2023/08/31(목)

• React Router & Sass 강의(10시~12시)
  • Routing, SPA
  • Sass
• Server Communication (14시 ~ 15시 30분)
  • HTTP/S
  • RESTful API 기초

2023/08/31(금)

• 1주차 돌아보기 및 과제 리뷰 , Gitbub Kickoff(10시 ~ )
• 조별 멘토 상담(15시30분 ~ )

한 주 마무리

• wecode에서의 한 주의 기록과 한 주를 돌아보며 느낀 점, 내가 부족하고 궁금한 부분을 velog에 적는 습관을 가져가려 한다.(과연 끈기 있게 잘 기록할 수 있을까…)
• 매 주의 기록을 적고 강의 중 부족한 부분은 기술블로그를 적은 velog링크를 통해 연결할 생각이다.
• 생각해 보면 기본적인 강의의 내용이 전부겠지만 내용을 정리하며 한 번 더 복습한다는 생각으로 정리를 하는 것도 좋지 않을까 생각한다.
• 위 코드의 커리큘럼이 너무 좋다고 생각한다. 마냥 프로그래밍 강의와 과제의 반복이 아닌 중간중간 개발자의 마인드 셋, 어떤 개발자가 되어야 하는지 생각해 보는 시간이 있다는 점이 너무 좋게 다가온다.

PS.

근데 왜 velog에 span 태그는 지원하고 mark 태그는 지원을 안 할까 ㅠㅠ 수정 작성 페이지에서는 지원하는데 작성 완료하고 보면 적용이 안된다..

• HT : HyperText (HTML)

• T : Transfer (전송)

• P : Protocol (협약, 통신 규약)

  ==> HTML 파일을 주고받을 수 있도록 하는 소통 방식 또는 약속

HTTP의 특징

• Request(요청) / Response(응답)

  • Stateless (상태 없음)

HTTP 메시지 구조

• Request

  • Start Line

    • HTTP method : 요청이 의도한 액션을 정의(GET, POST)
    • Request target : 해당 request가 전송되는 목표 url
    • HTTP version : HTTP 버전을 뜻함. 주로 1.1 버전이 널리 쓰임

  • Headers 해당 요청에 대한 메타 데이터(추가 정보)를 담고 있는 부분Key

    • {key: value} 형태

  • Body 해당 요청의 실제 내용이며 요청 메서드에 따라 내용이 없을 수도 있음

• Response

  • Status Line
    • HTTP Version
      • Status Code : 응답 메시지의 상태 코드 (200, 404 ..)
      • Status Text : 응답 메시지의 상태를 간략하게 설명해 주는 텍스트 (OK, Not Found.. )
  • Headers
  • Body

HTTPS란 ?

HTTP 프로토콜 + SSL(Secure Sockets Layer) 프로토콜 -> 클라이언트와 서버가 주고받는 텍스트를 암호화

다른 경로(url 주소)에 따라 다른 View(화면)를 보여주는 것

SPA(Single Page Application)

html이 하나인 웹 애플리케이션

React-Router

• 설치 방법

  npm install react-router-dom

  설치 후 package.json의 dependencies항목에 react-router-dom가 추가 되었는지 확인 필요

  • Router.js 작성

    // Router.js
    
    import React from 'react';
    import { BrowserRouter, Routes, Route } from 'react-router-dom';
    import Nav from './components/Nav/Nav';
    import Footer from './components/Footer/Footer';
    import Login from './pages/Login/Login';                    
    import Signup from './pages/Signup/Signup';                  
    import Main from './pages/Main/Main';                       
    
    const Router = () => {
    return (
       <BrowserRouter>
           <Nav />                                           // nav 컴포넌트
     <Routes>
       <Route path='/' element={<Login />} />               
       <Route path='/signup' element={<Signup />} />        
       <Route path='/main' element={<Main />} />            
     </Routes>
           <Footer />                                        // footer 컴포넌트
    </BrowserRouter>
    );
    };
    export default Router;
    

  1. react-router-dom 패키지에 BrowserRouter, Routes, Route 컴포넌트를 import한다.
  2. BrowserRouter 컴포넌트로 전체를 감싸준다.
  3. BrowserRouter 컴포넌트의 자식 요소로 Routes 컴포넌트를 넣어준다.
  4. Routes 컴포넌트의 자식 요소로 Route 컴포넌트를 넣어준다.
  5. Route 컴포넌트의 path 속성에 따라 화면에 그려줄 UI를 담은 컴포넌트를 import 한다
  6. Route 컴포넌트의 path 속성을 설정해 주고, 설정한 경로(url)로 이동했을 때, 화면에 그려질 UI를 담은 컴포넌트를 element 속성에 설정한다.

• index.js

  // index.js
  
   import React from 'react';
   import ReactDOM from 'react-dom/client';
   import Router from './Router';
  
   const root = ReactDOM.createRoot(document.getElementById('root'));
  root.render(<Router />);

  • Route 이동 (화면 이동 방법)

    1. Link 컴포넌트 사용
    • 클릭 시 바로 페이지를 이동하기 때문에, 조건 없이 페이지를 이동할 때 적합하다.
      • Nav Bar의 메뉴 혹은 Aside Menu 등 바로 페이지를 이동하는 경우 사용하는 것이 좋다. ex)

        <Link to='/signup'>회원가입</Link>

    2. useNavigate hook 사용
    • 조건에 따라 페이지를 전환해야 할 때 사용하기 적합 ex)

      // Login.js
      

    import React from 'react'; import { useNavigate } from 'react-router-dom'; // 1

    const Login = () => {

     const navigate = useNavigate();                             // 2
    
     const goToMain = () => {                                    // 3
       navigate('/main');
     };
    
     return (
           <button className='loginBtn' onClick={goToMain}>          // 4
             로그인
           </button>
     );

    }

    export default Login;

Sass & Scss

SASS 설치 : npm install sass

설치 후 package.json의 dependencies 확인 필요 !

Sass는 CSS 전처리기다.

실제 실행 전에 처리를 해줘서 브라우저가 읽을 수 있는 CSS 파일로 변환해 주는 일을 한다. 기존 CSS 파일에서 겪었던 불편한 부분들이 Sass를 사용하며 해결할 수 있다.

sass를 설치하고 기존 css파일의 확장자 명을 scss로 변경하면 scss 문법이 사용 가능하다.

Sass의 활용

• Nesting ⭐️⭐️⭐️ className이 겹쳐 css가 망가지는 문제를 해결하기 위해 HTML 구조처럼 자식 관계에 있는 스타일을 품고, 그 안에 다른 태그들의 스타일을 적용하는 방법으로 구현할 수 있다. 이러한 방법으로 className이 중복되어도 부모가 다르면 다른 스타일이 적용 된다.

• 변수 여러 곳에서 사용되거나 오타가 나기 쉬운 속성을 변수로 저장하여 사용 가능하다.

• & 선택자 &는 부모 선택자로 치환하여 사용 가능하다.

• mixin ( @mixin 변수 이름 { 여러 가지 스타일 속성 } )처럼 사용하여 중복되는 스타일을 묶어서 사용 가능하다. 또한 인자를 받아 함수처럼 사용 가능하다. ( @include 변수 이름 )으로 사용가능하다.

강의 들으면서 궁금한 점

Q : a태그에 onclock 이벤트로 navigate함수 사용을 하면 Link태그와 같은 역할을 하나? A : a 태그보다 Link 태그가 속도적인 측면에서 강한 건 알겠지만 위 방법을 사용하면 같은 게 아닐까 생각해 보았지만 아무리 찾아도 이런 질문을 하지 않아 해결하지 못했다..

Q :Link태그 css 는 a태그에 줘야하는가? A : Link 태그는 가상의 태그로써 컴파일 시 a태그로 바뀐다 따라서 a 태그에 스타일링 하면 된다

페이스북에서 개발하고 관리하는 사용자 인터페이스(UI)를 만들기 위한 자바스크립트 라이브러리

React의 특징

• 선언적 : 문제를 어떻게 해결할 것인가에 중점을 두는 것이 아닌 무엇을 해결할 것인가에 중점을 둔다

• Virtual DOM : 이전 UI 상태를 메모리에 유지하는 가상 DOM을 통해 변경될 UI의 최소 집합을 계산하여 DOM 처리 횟수를 최소화하고 효율적으로 진행

• Component : 컴포넌트(Component)란 재활용 가능한 UI 구성 단위

  • 특징

    필요한 곳에서 재사용할 수 있다. 독립적으로 사용할 수 있기 때문에 코드의 유지보수에 좋다. 또 다른 컴포넌트를 포함할 수 있다. 해당 페이지가 어떻게 구성되어 있는지 한눈에 파악하기 좋다.

JSX

• 리액트에서 사용하는 자바스크립트 확장 문법

• HTML 태그와 유사한 형태로 사용하기 때문에 보기 쉽고 익숙하다.

• 별도의 .html, .js 파일이 아닌 하나의 자바스크립트 파일에서 HTML 마크업과 자바스크립트 로직을 동시에 작성할 수 있기 때문에 편리하다.

• 문법

  • Javascript 표현식 : { } 안에 유효한 자바스크립트 표현식을 작성
  • 자바스크립트 파일 어디에서나 필요한 곳에 HTML처럼 작성
  • attribute name(속성명)은 camelCase로 작성 -> 기존 Html 속성과는 조금 다를 수 있음 (class => className 등등)
  • Event 처리 : 이벤트는 앞에 on을 붙여 camelCase로 작성(onClick={함수명} 등등)
  • style 속성 : 중괄호를 두 번 겹쳐서 쓰는 형태(style={{ color: "red", backgroundImage: "yellow" }})
  • Self-Closing Tag
  • Nested JSX : 반드시 최상위를 감싸고 있는 하나의 태그가 있어야 한다.

깃과 깃허브에 관한 내용은 많은 정리가 필요하겠지만 일단 가장 기초적이고 기본적인 정리만 하는 것을 목표로 하고 정리해야겠다.(git 설치와 설정이 끝났다는 가정)

Git 기본적인 흐름

init(초기에 한 번만) -> add -> commit -> push

Repositories(저장소)

Repositories란 Git으로 관리하는 프로젝트 저장소

• Local repository - 본인의 컴퓨터에 저장된 로컬 버전의 프로젝트 저장소
  • Remote repository - Local repository 와는 반대로 내 컴퓨터가 아닌 외부 버전의 프로젝트 저장소. 프로젝트 코드를 공유, 다른 사람의 코드를 확인, 로컬 버전의 프로젝트와 병합, 변경 사항을 적용 하는 공간

명령어

• init

  새로운 Repositories(저장소)를 만들고 프로젝트 관리를 시작하는 명령어

  git init

• status

  repository의 현재 상태를 확인하는 명령어

  git status

• add

  파일들을 staging area(곧 커밋할 파일에 대한 정보를 저장하는 곳) 로 추가해주는 명령어

  • 한개의 파일 : git add 파일명
  • 여러개의 파일 : git add 파일명 파일명
  • 전체 파일 : git add .

• commit

  특정 시간의 코드 스냅샷의 형태로 해당 repository의 커밋 기록하는 명령어 staging area에 있는 파일들을 커밋한다.

  git commit -m "남길 메시지"

• git log

  프로젝트의 모든 커밋 내역을 보는 명령어 (hash값 포함 자세한 내용)

  git log

  특정 커밋 시점의 코드로 되돌리는 명령어

  git checkout (hash값)

• branch

  • branch란 독립적으로 어떤 작업을 진행하기 위한 개념

  • 저장소를 처음 만들면, Git은 바로 'master' or 'main' 이라는 이름의 브랜치를 만듦

  • 'master'가 아닌 또 다른 새로운 브랜치를 만들어서 '이제부터 이 브랜치를 사용할거야!'라고 선언(체크아웃, checkout)하지 않는 이상, 이 때의 모든 작업은 'master' 브랜치에서 이루어 진다.

  • branch 생성

    git branch (생성 할 branch명)

    • branch 이동

      git checkout (branch명)

    • branch 병합

      git merge (병합 할 branch명)

    • branch 삭제

      git branch -d (삭제 할 branch명)

• push

  commit이 끝난 새로 추가한 기능을 GitHub repository 에 반영하는 명령어

  git push origin (내 branch명)

• clone

  GitHub remote repository 를 내 컴퓨터로 받아오기 위한 명령어

  git clone (GitHub remote repository URL)

• pull

  remote 의 최신화된 코드를 내 로컬 repo 에 반영하는 명령어

  git pull origin (master or main)

GitHub

GitHub은 Git을 사용하는 프로젝트를 위한 호스팅 서비스

로컬 프로젝트 repository를 원격 클라우드 기반 GitHub 저장소에 업로드 할 수 있고, public repository 들을 통해 다른 개발자들과 교류할 수도 있다.

Pull Request (PR)

프로젝트 오너 (혹은 팀 리더) 에게 내가 작업한 브랜치의 작업내용을 master 브랜치에 반영해달라는, 다른 사용자에게 푸쉬된 상황을 알리는 과정