8월 9일 - 1차

일반적인 웹 서비스에서의 웹 프론트엔드 구현 포인트

• 1) 서버에서 데이터를 잘 받아다가 → 사용자에게 잘 보여준다
• 2) 사용자에게 입력을 잘 받아서 → 서버로 잘 보내준다

서비스 전체적인 관점에서 보면 웹 프론트엔드는 사용자와 서버 / DB 사이에 존재하는 입출력 인터페이스

중요 포인트

1 상태 관리

리덕스,,,, 는 잘 몰라서... 리덕스 프로세스에 대한 것은 공부가 좀 필요할 것 같다는 생각

대신 리덕스 와 같이 리액트에서 상태 관리를 하는 리코일을 배웠기 때문에 상태 관리 자체에 대한 것은 이해할 수 있었다.
웹 프론트엔드는 앱 여러 부분에서 각 요소의 상태를 관리해야 하는데 서버에서 받아오거나 ( 로그인 유저의 정보 ), 유저가 입력한 상태 등이 여러 컴포넌트에 뿌려져 있는 경우가 많고, 멀리 떨어져 있는 컴포넌트에서 사용해야 할 수도 있다. 이렇게 전역에서 상태 관리를 위해 쓰는 경우가 있음!

Input이 많은 Form에서 제어 컴포넌트(state)와 비제어 컴포넌트(ref)도 있음
상태 관리는 리액트에서 가장 중요한 포인트

2 비동기, 캐싱

promise : 서버에 요청을 보내놓고, 미래에 성공/실패라는 응답을 돌려줄 것이라는 약속
resolve : 약속이 잘 지켜진 상황
pending : 기다리고 있는 상황

대기 상황에 사용자는 ?
로딩바 , 스피너, 스켈레톤 등을 활용한 대기 화면을 보게 된다

Cache : 미리 받아놓은 결과가 있었다면, 추가 요청을 보내지 않아도 된다
Rejected : 약속이 잘 지켜지지 않을 수도 있다
Retry : 다시 요청할 수 있다

3 인증/인가

• 인증 (Authentication) : 신원 확인
• 인가 (Authorization) : 권한 검증
• 횡단 관심사 : Cross Cutting Concern (권한분기)
  => 각 버튼에 별도 로직을 작성하는 것보다 일관되게 처리하는 방법을 찾자

4 UI/UX

유저가 액션을 했을 때의 피드백 주는 것
alert => 실패 했다면 인지할 수 있도록, 삭제/업뎃 (파괴적 동작) 할 때

• 스켈레톤
  

Cumulative Layout Shift(누적 레이아웃 이동, CLS)

데이터가 나오기 전에 자리를 미리 차지해놓고 있어야, 레이아웃이 나중에 이동하지 않게 된다

시각적 요소 + 웹 접근성(스크린 리더, 키보드) + SEO (검색최적화) => 사용자 친화적 웹 서비스 만들기 위한 지식 및 구현 연습

5 관심사의 분리

• 유저 인터페이스(View)와 비즈니스(Business, Domain) 로직의 분리
• View
  • 사용자와 애플리케이션이 화면 상에서 상호작용 하는 영역
  • 데이터를 화면 상에 표시하는 영역
  • ex. Image, Form, Button 등
  • ex. 외부에서 주입 받은 props에만 의존하는 순수함수적 컴포넌트
• Domain(Business) Logic
  • 현실 세계의 비즈니스 규칙
  • 개발 시스템 전체 관점에서 웹은 세부사항에 가깝기 때문에 백엔드 서버 측 API에 많은 디펜던시가 있음
  • API 호출 로직을 view 로직과 분리하는 것만으로도 어느 정도 관심사의 분리를 달성할 수 있음
• 의존성 역전 원칙 (이해 못함,, 공부하자 ^^;; - 클린 아키텍쳐)

과제 리팩토링을 위한 피드백

변수명 ?

구현 방식 대신 무엇인지를 나타내는 변수명 (How vs What ) 을 선택하여 개발자의 의도를 드러내기

• 타입별 변수명
  • boolean : is-, has-, can-, ...
  • function : get-, handle-, submit-, …
  • array : -s (ex. users.map(user ⇒ user.id)), …
• 피해야 할 변수명
  • data, info, foo, user1, mdhms, …

명령형 프로그래밍과 선언형 프로그래밍

명령형은 특정한 동작을 어떻게(How) 달성할 것인지에 집중하고, 선언형은 무엇을(What) 할지에 집중

적절히 추상화 되지 않은 함수와 컴포넌트

DRY(Don’t Repeat Yourself)라는 원칙 => 중복 코드를 만들지 말라는 뜻
같은 로직을 10군데서 썼다가, 버그가 발견되면? vs 1번 썼다가, 버그가 발견되면?

단일 책임 원칙 을 따르라 => 하나의 함수가 한 가지 일을 하도록 코드를 작성

회고

• 주 2회 3시간 강의로 진행되는데, 1회차의 초반 1-2교시가 조금 더 압축적으로 진행되었어야(ㅜㅠ)
• 프론트엔드 중요 포인트 ~ 과제 리팩토링 팁 부분이 굉장히 중요!
• api 방식이 아직 익숙하지 않아 과제 수행을 못했는데, 과제 수행을 못 한게 아쉬울 정도로 생각보다 꼼꼼히 코드리뷰를 해주신 것 같다. 잘 한 코드 vs 개선점이 있는 코드를 비교 해서 볼 수 있어서 어떻게 쓰면 좋을지 감을 많이 얻었던 것 같다.
• 400명이 넘는 , 무료인 챌린지 강의인데도 이렇게 코드를 봐준다고? 놀랐다.... 물론 일찍 낸 학생들 몇 명 정도만 보셨겠지만 굉장히 자세하게 보신 것 같아서 놀랐다.
  - 부트캠프에서도 코드를 그렇게 봐준 사람,,,없었던 것 같은데 (ㅋ)
• 어쨌든 직접 해봐야 좋은거니까,, 아무래도 개인 포폴은 다음주에 하고 이번주 남은 시간은 위에서 배운 것 토대로 팀프로젝트 리팩토링 & 과제 수행을 해봐야겠다..