[2021.08.09] 리액트에서 좋은 코드

이다은·2021년 8월 9일
1
post-thumbnail

📌 1. 기업과제 Review

💡 event handler는 JSX에 로직 구현하지 말고 꼭 따로 빼기

  • (변경 전)
    onChange안에 로직을 구현하면 가독성이 떨어진다.
<CheckBox
      key={idx}
      value={name}
      checked={filter?.includes(name)}
      onChange={(e) => {  // ❌
        if (e.target.checked) {
          onChange([...filter, name]);
        } else {
          filter.length === brand.length
            ? onChange([name])
            : onChange(filter.filter((opt) => opt !== name));
        }
      }}
/>
  • (변경 후)
    함수를 새로 생성해서 마크업 가독성을 높여주자!!
 const handleCheckBoxChange = (name, e) => { // ✅
      if (e.target.checked) {
        onChange([...filter, name]);
      } else {
        filter.length === brand.length
          ? onChange([name])
          : onChange(filter.filter((opt) => opt !== name));
      }
};
return (
  //생략..
    <CheckBox
      key={idx}
      value={name}
      checked={filter?.includes(name)}
      onChange={(e) => handleCheckBoxChange(name, e)} // ✅
    />
);

💡 css에서 할 수 있는건 css에서 처리하기

  • (변경 전)
    디바이스, 브라우저 환경에 따라서 제시되는 글자수는 다를 수 있다.
const titleName = title.length > 25 ? title.substring(0, 25).concat("...") : title;
  • (변경 후)
    css를 사용해서 화면에 예쁘게 나오도록 수정한다.
  overflow: hidden;
  white-space:nowrap; // 공백 문자를 처리하는 법을 지정
  text-overflow:ellipsis; // 박스 안에 내용이 넘칠 때 텍스트를 어떻게 처리할지 지정

📌클린코드

💬 변수(Variables)

  • 의미있고 발음하기 쉬운 변수 이름을 사용하자
  • 동일한 유형의 변수에 동일한 어휘를 사용하자

💬 함수

1. 함수인자

  • 함수 인자는 2개 이하가 이상적

    • 매개변수의 개수를 제한 하는 것은 함수 테스팅을 쉽게 만들어 주기 때문에 중요하다
    • 매개변수가 3개 이상일 경우엔 테스트 해야하는 경우의 수가 많아지고 각기 다른 인수들로 여러 사례들을 테스트 해야한다
  • es6의 비구조화(destructuring) 구문을 사용

    • 함수가 기대하는 속성을 좀 더 명확하게 나타낸다.
    • 어떤 속성이 사용되는지 즉시 알 수 있다.
    • 비구조화는 함수에 전달된 인수 객체의 지정된 기본타입 값을 복제하며 이는 사이드이펙트가 일어나는 것을 방지한다
    • Linter를 사용하면 사용하지 않는 인자에 대해 경고해주거나 비구조화 없이 코드를 짤 수 없게 한다.
  // ❌ 안좋은 예
  function createMenu(title, body, buttonText, cancellable) {
    // ...
  }
 // ⭕ 좋은 예
  function createMenu({ title, body, buttonText, cancellable }) {
    // ...
  }
  createMenu({
    title: 'Foo',
    body: 'Bar',
    buttonText: 'Baz',
    cancellable: true
  });

2. 함수는 하나의 행동만 해야한다!! (중요!!)

  • 함수가 1개 이상의 행동을 한다면 작성하는 것도, 테스트하는 것도, 이해하는 것도 어려워진다.
    하나의 함수에 하나의 행동을 정의하는 것이 가능해진다면,
    함수는 좀 더 고치기 쉬워지고 코드들은 읽기 쉬워진다!!!
// ❌ 안좋은 예
function emailClients(clients) {
  clients.forEach(client => {
    const clientRecord = database.lookup(client);
    if (clientRecord.isActive()) {
      email(client);
    }
  });
}
 // ⭕ 좋은 예
function emailClients(clients) {
  clients
    .filter(isClientActive)
    .forEach(email);
}
function isClientActive(client) {
  const clientRecord = database.lookup(client);
  return clientRecord.isActive();
}

3. 함수는 단일 행동을 추상화 해야한다.

  • 추상화된 이름이 여러 의미를 내포하고 있다면 그 함수는 너무 많은 일을 하게끔 설계된 것!
  • 함수들을 나누어서 재사용가능하고 테스트하기 쉽게 수정해야 한다.

4. 매개변수로 플래그(boolean type)를 사용하지 말자

  • 플래그를 사용하는 것 자체가 그 함수가 한가지 이상의 역할을 하고 있다는 것을 뜻한다.
  • boolean 기반으로 함수가 실행되는 코드가 나뉜다면 함수를 분리해야 한다.

5. 전역 함수를 사용하지 말자

  • 전역 환경을 사용하는 것은 JavaScript에서 나쁜 관행
    (예전에는 아래코드 처럼 prototype 에 diff 함수를 추가해서 개발하곤 했다.)
Array.prototype.diff = function diff(comparisonArray) {
  const hash = new Set(comparisonArray);
  return this.filter(elem => !hash.has(elem));
};
  • 그러나 위와 같은 코드를 사용하면 다른 라이브러리들과의 충돌이 일어날 수 있다.
  • 유저들은 운영환경에서 예외가 발생하기 전까지는 문제를 인지하지 못하므로 전역 함수를 사용하지 말자

📌 React로 사고하기

💡 컴포넌트 분리

  • 하나의 컴포넌트는 한 가지 일을 하는게 이상적
  • 하나의 컴포넌트가 커지게 된다면 이는 보다 작은 하위 컴포넌트로 분리되어야 한다.

💡 state

  • state는 오직 상호작용을 위해, 즉 시간이 지남에 따라 데이터가 바뀌는 것에 사용되어야 한다.

    • 정적 버전을 만들기 위해 state를 사용하지 말자.
      ➡ state에 전역상수, 스타일 값 등 정적인 데이터를 사용하면 안된다.
  • 중복배제원칙 : 애플리케이션이 필요로 하는 가장 최소한의 state를 찾자.

    • 예를 들어 TODO 리스트를 만든다고 하면, 배열에 대한 정보만 state에 넣으면 된다.
      ➡ 배열에 대한 길이(length)값은 굳이 별도로 만들지 않아도 알 수 있는 정보니깐!

📌컴포넌트 내 변수 위치

// 1. import 순서도 경로(or연관)에 따라 묶어주자
// ex) 멀리 있는 것 부터 차례대로

// 2. propType

// 3. 컴포넌트 정의

// 4. Styled Component

// 5. 간단한 상수 설정

// 6. 해당 컴포넌트에서만 사용할 함수

1. import도 술술 읽힐 수 있도록 해야 한다.
이 파일에서는 어떤 것들이 필요하구나! 알 수 있도록. 가독성을 위해 import 분류별로 한줄 띄워도 괜찮다.

  • a. node modules 먼저
  • b. utils 같은 함수
  • c. 멀리 있는 컴포넌트
  • d. 근처에 있는 컴포넌트
  • e. style 관련한 것들

2. ts를 안 쓰는 경우, 있으면 좋다.

  • 타입오류를 막아주는 것도 있지만,
  • propType만 보고 컴포넌트 내에서 어떤 형식의 값을 관리하고 있는지도 알기 좋다.
    (그렇지 않으면 코드를 하나하나 다 읽어야 해서)

3. 컴포넌트부터 정의하여, 이 컴포넌트가 무슨 역할을 하는지 한 번에 알아볼 수 있도록 하자.

  • 리액트는 컴포넌트 중심.
  • 상단에 상수 설정이나 styled component 가 정의 되어있다면, 이 컴포넌트가 뭐하는지 바로 알기 어렵다.

4. styled component 썼다면, 컴포넌트 다음에 정의

5. 간단한 상수 설정, 간단한 data 등.. 혹시 data가 객체에 너무 길면 외부 파일로 분리하자.

6. 공통으로 사용하는 utils 성 함수는 아닌 경우, 로직인 경우 밖으로 빼자.

  • 5, 6번의 이유는 컴포넌트 내부에서 state, props와 상관없는 코드가 있을 때, 렌더링할 때마다 불필요한 생성을 피할 수 있어서 성능에 좋다.
profile
단단_프로트엔드개발자!

0개의 댓글