조은의 프론트엔드 개발 실무 가이드 : 요구사항 분석과 적정 기술 (4-1)
패스트캠퍼스 The Red
Next 기반 애플리케이션 개발하기
패스트캠퍼스 사이트 Next.js로 구현하기 (TypeScript 기반)
CH04_01. 데이터 플로우 그리기
Data Flow: 실제 개발 진행 전큰 그림그리기
이 데이터는 정제해야하는 데이터인가?
이 데이터가 어디서 흘러오는 걸까?
흘러온 데이터를 어느 시점에 어떻게 정제해야할까?데이터가 흘러오는
구조를 생각하기
API로? 설정 파일로? Mock Data로?프론트엔드 개발자가 종종 하는 실수
- 일단 화면에 보이는 것부터 구현하는 실수
- 뒤에 관리되고 있는, 쌓여 있는 데이터에 대한 망각하고 구현하는 실수
- 하드코딩 후 설계를 나중에 생각해서 리팩토링하게 되는 것
HTML이나 JSX 작성이나 하드코딩은 너무도 쉬운 일이기 때문에
나중에 정작 고치려고 보니... 어 이거 어디서부터 고쳐야 하지??..
어, 이게 데이터 설계가 잘못됐네
그럼 데이터를 통째로 뜯어고쳐야하는데 이거 리팩토링을 해야하나..?
이건 백엔드 개발자의 도움을 받아야 겠는데... 프론트엔드 개발자가 하는 가장 큰 실수
데이터
언제나 데이터 플로우를 먼저 그리고 시작하자!Data Flow
패스트캠퍼스 (온라인 강의 학습 사이트 분석)
인증
- OAuth, Cookie, Session
- 인증을 어떻게 하느냐에 따라
앞뒤 flow가 바뀐다- 인증을 한 유저와 안한 유저가 입장할 수 있는 페이지가 다르다
- 유저 단위로 접근 권한 달라짐
외부 주입 데이터
- API, 3rd Party API
내부 주입 데이터
- Project/Package 내부
=> 나누는 기준 : 관리포인트 (어디서 쓰는 데이터야? 관리 주체 - 부서, R&R)
=> 예 : 강의목록 API에서 강의 분류할 때 T/F 필드 데이터 받아오기, 쿼리 파라미터 (분기)
=> 데이터를 정리하는 행위가 중요
=> 나누다보면 그게 MSA
- 수정에 대한 Needs
- Admin이 있다면 직접 수정하거나
메뉴- (API 공통) -카테고리/GNB
하나의 API가 여러가지 일을 수행할 수 있다 (단일 책임 원칙 위배)
API 설계 시 FE와 BE가 함께 협업 (충분히 논의)
배너
- 어드민에서 순서 변경, 데이터 제어
강의 목록강의 상세
API가 같은 데이터를 바라보고 있을 가능성
불필요한 데이터를 추가하지 않도록 API 한 덩어리가 너무 크지 않게
The Red Hero
클라이언트에서 관리하는 영역 (Next.js 내부에서)
추천 키워드
썸네일에 있는 업무들은 자주 바뀌지 않는 거라 내부 API에서 관리
이벤트 목록카테고리
Mock API
백엔드에게 역제안 (이런 데이터가 필요하다고 가이드)
그렇다면 유저는 어떻게 데이터를 활용하게 될까?CH04_02. 유저 시나리오 작성하기
유저가 이 사이트에 접속했을 때 어떤 액션, response는 어떻게 진행될 지 등 시나리오 정리
비회원이냐? (lock-in되지 않은 유저, 눈팅족)
회원이냐? (lock-in된 유저, 구매까지는 아직)
구매 회원이냐? (lock-in도 되고, 구매도 한 => 지금 내가 듣고 있는 강의를 메인에 노출시키기)
어드민인가? (내부 직원 권한인 사람이 보는 화면은?)
유저 시나리오 작성하기
타겟유저정하기공통
- 메인 페이지에 접속할 수 있어야 한다
- 로그인 할 수 있어야 한다.
- 회원가입을 할 수 있어야 한다
- 메뉴가 노출되어야 한다.
Edge PointFE와 BE의 관점에서 함께 정리
(업무 관계자 - 개발자, 기획자, 디자이너, 업무 담당자(마케터))
메뉴
- 카테고리 버튼이 보여야 한다
- 카테고리 버튼에 마우스를 올리면 메뉴가 확장된다
- 최신 혹은 어드민이 지정한 메뉴가 상단 노출
ㄴ 어드민이 지정한 메뉴 : XXX API 호출
ㄴ 메뉴는 어드민이 N일에 한번씩 변경- 메뉴는 메인메뉴와 서브메뉴가 존재한다
- 서브메뉴는 메인메뉴에 묶여있는 그룹에 한해서 노출
- 강의 전체보기 클릭하면 강의 목록으로 넘어간다
배너
- 어드민에서 지정한 배너가 상단 노출
- 배너는 5초마다 자동 롤링 (클라이언트 단에서 시간 지정)
- 미리 const로 빼내기
유저가 컴포넌트를 사용하는 모든 case에 대해 정리한 내용을 바탕으로 실제 test case > code
(개발자 관점에서 정의)강의 목록
- 4단 그리드로 보여주어야 한다.
옵션- 특정 카테고리의 강의 목록이 노출되어야
- 특정 옵션의 강의 목록이 노출되어야 함 (각 카테고리별)
ㄴ 특정 옵션, 태그 ,카테고리- 목록형/슬라이드형
- 강의 제목, 요약, URL
실제로 구현해보고 문제 발생 시 데이터 플로우를 다시 생각해보기 (뭐가 문제였지?)실제 API가 없는 상태에서 만들기 : Next API
데이터 플로우에 대한 이해
CH04_03. 페이지 생성하기
페이지 단위로 결정하게 되는 경우
testing-library.js : 테스트 코드부터 작성해두기 (렌더링 관련)
Index.tsx에 렌더링되어야 하는 요소들에 대한 테스트 코드 작성 시작 후 진행정상동작/에러 체크 Tip
- Testing Library 문서 참조 https://testing-library.com/docs/queries/about
- MDN 검색 참조 https://developer.mozilla.org/ko/
/**
* @jest-environment jsdom
*/
import React from 'react'
import { render } from '@testing-library/react'
import Index from '../pages/index'
describe('App', () => {
it('강의 목록이 렌더링 되어야 한다', () => {
const { getByTitle } = render( <Index />)
const lectureList = getByTitle('lectureList'})
expect(lectureList).toBeInTheDocument()
})
// default test
// it('renders a heading', () => {
// const { getByRole } = render( <Index /> )
// const heading = getByRole('heading', {
// name: /welcome to next\.js!/i,
// })
// expect(heading).toBeInTheDocument()
// })
})npm run test:watch
💎 Point
테스트코드를 먼저 작성해야 내가
어떤 걸 개발하는구나인지할 수 있다
당장은 cases가 깨지더라도현재 잘 진행되고 있는지 검증하는 것이 중요
💬 Next.js와 함께 TypeScript도 익혀볼 수 있는 강의라 좋다(Type 지정만 추가로 하는 게 기본인 듯?)
💬 강의 수강 이후에 TypeScript 기본도 정리할 생각이다 (만들어보고 개념 정리하기 vs 개념 이해하고 만들기)
💬 마지막 4챕터는 3분량으로 나눠서.. 열심히👊🔥
