프론트엔드 코드 컨벤션, 주로 사용하는 디자인 패턴, 컴포넌트 분리 전략

이제는 사용하지 않는 or 잘 사용을 많이 안하는 안티패턴

 

1. 헝가리안 표기법

- 접두어(prefix) 사용 X

ex) IComponentProps

 

2. useMemo, useCallback X

- 19버전을 사용하면 사용할 필요없다. (최적화 용도로)

- 리액트 컴파일러가 최적화를 해준다.

- 메모리 주소값으로 비교하는게 리소스가 많이 들어서 최적화는 비용이 많이 든다. (최적화 용도)

- 배열, 숫자, 문자 렌더링될때마다 메모리 값이 동일 
/ 함수같은 경우는 값이 달라질 수 있음. 가변적인 객체 값을 고정시켜줄 때 사용. useEffect에서 아예 안넣은 거 = useMemo의 빈배열. 바뀌는 값을 묶어놓기 위해서 사용하는건 사용할 수 밖에없음. 

함수는 호출되면 메모리 주소가 바뀜. - useCallback으로 씌워두면 리렌더링되어도 메모리 주소가 바뀌지 않음. (참조 동일성)

객체면 useMemo, 함수는 useCallback

useCallback -> 메모리 주소가 변동되지 않게 하기 위해서

useMemo -> 정확한 트래킹을 하기 위해서  + 메모리 주소가 변동되지 않게 하기 위해서

차이는 함수를 리턴 vs 값을 리턴

 

- Object.is라는 메소드를 이용해서 비교 ( useEffect 내의 dependancy array 비교 방법)

 

cf) useCallback, memo 으로 감싼 함수는 컴포넌트로 사용가능하다

 

3. class component 

- 거의 쓰지 않지만 class component만의 생명주기가 필요할 때가 있어요 (ex 에러바운더리)

- componentDidCatch, ~Error 생명주기는 class에만 존재 (cf. react는 생명주기가 useEffect 하나로 퉁쳐져있음)

- 위 2개 생명주기는 좀 알아두자

 

4. 함수형으로 작성하자

- map, reduce, filter, find 모두 함수형 프로그래밍의 일부

- for문이 속도는 더 빠르다 하지만 컨벤션 챙기자

- reduce 보다 fromEntries가 조금 더 빠르다

 

5. let, var 지양

- let을 쓰면 함수형 프로그래밍이 아닐거임. 어지간해서 쓸 일 없다. 함수형으로 바꿔보자.

 

6. not use export default

commonJs vs es module

named export가 아니라 default export를 못 알아먹을 때가 있음. 

(export function 이름 () {} 형태로 쓰자)

 

7. type import 쓰자

typescript를 import 할 때 import type {A} from './type'; 형태로 쓰기

why?

- import 하자마자 export하는 형태로 쓰면 type인지 값인지 몰라서 남아버림. (cf. typescript 빌드할 때 type은 다 날라가고 값만 남는다.  )

- 가독성

- 이유 더 찾아보기

 

 

컨벤션

1. 이벤트 핸들러 네이밍

선언할 때는 handle, props로 내릴땐 on

 

2. 화살표함수, 함수선언문(function)

- 화살표 함수 - this 범위를 자동으로 바인딩해주는 특징이 있음. 메서드를 쓸 때 많이 안쓰는 편. 편한데 문제가 있을 수도 있어서.

 $Button.addEventListener(callback);

: addEventListener -> 강제로 $Button에 바인딩. this는 $Button을 본다.

- 리액트에서 단축이 된다는 점이 화살표 함수 장점 (Ex. const A = () => 1;)

-  컴포넌트 선언할 때, 밖에서 함수 선언할 때 : 함수선언문

 export function Example() {}

 export function a = () => {}

- 컴포넌트 내에서 메서드 선언할 때 : 화살표함수

 

3. 주석으로 설명을 달아주자

- 왜 썼는지 설명해주는 주석도 좋다

- jsdoc : 라이브러리, 디자인 시스템 만들때 유용하다.

- params, url, description, deprecated 등등은 많이 쓰임

 

4. editorconfig, eslint, prettier

prettier : 포맷팅 도구. 포맷팅 해야 적용됨

editorconfig: 칠 때 바로 적용된다

 

컨벤션을 rule로 할 순 없을까?

- eslint 통해서 커스텀 룰

- ex) eventhandler는 handle로 시작한다 등

- 컴포넌트 이름은 대문자로 시작해야 된다.

- eslint, prettier가 ast트리(추상 구문 트리)로? 코드를 바꿔서 읽는다. 커스텀은 추상 구문트리를 만들어서 한다. 
  vscode는 ast트리 기반.

- 직접 커스텀한 컨벤션 예시 참고

  https://github.com/hwangstar156/eslint-plugin-server-component-rules

 

 

5. husky 쓰자

 

---

디자인 패턴

 

mvc 패턴

= model view controller

단점

- model view 깔끔 분리 안돼

- 상태가 많아지면 힘들어

 

flux 패턴

- 뭔지 알아보자 https://haruair.github.io/flux/docs/overview.html

- redux 가 대표적인 예시

- 보일러 코드가 단점 / store가 너무 커지는 단점

- 그래서 나온게 atomic 패턴

- jotai, recoil

 

[리액트 패턴]

- 관심사 분리가 핵심 (비즈니스 로직과 view를 분리했는가 / 책임(상태)이 있는가 = 상태를 업데이트해야되는 책임이있는가

- 하는 이유: 재사용

presentation container pattern

container = 비즈니스 로직

presentation = view

UI와 로직의 분리. 

 

high order component (고차 컴포넌트)

클래스형 컴포넌트에서 로직 공유하기 위해 쓰던 방식

클로저 써서 만든 것.

with를 꼭 앞에 써준다.

공통된 view를 사용하기 위해서 씀.

비즈니스 로직을 인자로 넘겨준다.

예시) withAuthentication(MyComponent) 

단점: 여러 로직을 주입해야 하면 너무 많은걸 감싸게 된다. (가독성 나쁨)

예시 찾아보기

 

render props 패턴

render로직을 호출

값을 view한테 넘긴다.

render props로 넘기는게 공통된 컴포넌트

각각 fetch하고 다른 결과를 render로 넘겨줌

단점: 콜백헬

 

custom hook pattern

로직은 커스텀 훅으로 분리 (관심사 분리하려고***)

두 가지  행동을 하는 컴포넌트는 옳지 않다. -> 컴포넌트 분리 전략으로 고고링

 

cf. useOutsideClick hook 살펴보기

 

---

컴포넌트 분리 전략

컴포넌트는 한 가지 동작만 해야 한다.

컴포넌트는 view를 기준해서 분리하지 말고, 행동을 기준해서!

도메인 중심 분리를 하자 (동작 = 도메인)

공통컴포넌트에는 기능을 아예 없애면 된다....! 로직은 주입해야한다는 생각을 항상 하자.

UI를 기준으로 하면 기능 추가될때마다 덩치가 커지는 문제가 생길 수 있음.

 

 

번외 - 상태 관리 라이브러리 흐름

context

redux, mobx : 보일러 플레이트 코드가 이슈

jotai, zustand : 용량이 작다. 

recoil: 쓰지말자. (용량도 큼)

 

jotai, recoil은 react에서 밖에 못쓴다.

redux-saga, redux-thunk -> 리덕스 개발 시 비동기 처리를 위해 반드시 둘중 하나는 사용함.

-> 관심사 분리가 잘 안되었음 / client 상태, 비동기 상태 / 하나의 스토어가 너무 커짐 / 2개의 상태가 깊게 엮여있음. (redux의 단점)

-> react query, swr의 등장 (등장 배경 더 잘 알아보기)

-> store 따로 관리할 수 있게 됨 ( 비동기 상태만 전문적으로 하는 (캐싱,...) react-query store가 생김, jotai/zustand 같은거로 client 상태 파악 )