<aside> 🔃 나만의 일관된 코딩 규칙을 세우자! 개발할때 편리하기 위한 것보다 변경할때 편리하기 위한 컴포넌트를 작성하자

</aside>

• 로직을 컴포넌트로 부터 분리하기위해, 커스텀훅 뿐만 아니라 children props로 생각을 해보자 ⇒ <LoginContainer/> : 로그인을 했을때 컴포넌트 렌더링 아니면 로그인 유도 컴포넌트

• UI 위치 요소를 결정짓는 것은 UI 컴포넌트 밖의 Wrapper에서 결정 짓는다. UI가 자체 위치 정보를 갖지 않는다

• 비슷한 UI 처럼 보이지만, Single Source of Truth인 백엔드 데이터 스키마가 다르다면 다른 컴포넌트로 분리한다.

• 데이터가 똑같은데, 보여주는 View가 다르다고 하면 render props 패턴을 이용한다.

• 부모에서 바로 Map을 돌리지 않는다. 중간 컴포넌트에서 Map을 돌린다.

  • Article ⇒ ArticleList(map돌림) + ArticleCard
  • 테스트 용이
  • 컴포넌트는 하나의 역할만 한다.

• 백엔드 DTO는 interface, 일반 타입은 type키워드 사용

  • props는 type ⇒ interface가 아닌 이유는 함수같은것은 이미 부모에 구현이 끝난 정보가 내려오기 때문
  • Type과 interface 의 역할을 고민해보자!

• UI 컴포넌트에서는 필요한 정보만 받는다 adapter를 만들어서, UI에 필요한 데이터만 싹 받는다. (고민 해봐야할듯?) 미션 카드 UI 참고

  • 같은 UI인데 데이터의 타입이 다르다면? getDto를 해주는 함수의 종류가 늘어날 수도 있다? ⇒ 근데 그래봤자 2개정도임

• State로 카테고리에 따라 다른 UI를 보여줘야하는 widgets (url로 카테고리가 바뀌어야하는 것은 별도임)

  CategoryRenderContainer

  컴포넌트에서 필요한것

  • 카테고리 state
    • {id string | number , label : string}
  • 카테고리 변경

• errorboundary로 감싸면, reset을 해준다.

  • 만약에 3번 했는데도, 안되면 더 상단의 에러로 던져 문제가 있다고 알려야할듯

  import { useQueryErrorResetBoundary } from '@tanstack/react-query'
  import { ErrorBoundary } from 'react-error-boundary'
  
  const App = () => {
    const { reset } = useQueryErrorResetBoundary()
    return (
      <ErrorBoundary
        onReset={reset}
        fallbackRender={({ resetErrorBoundary }) => (
          <div>
            There was an error!
            <Button onClick={() => resetErrorBoundary()}>Try again</Button>
          </div>
        )}
      >
        <Page />
      </ErrorBoundary>
    )
  }
  

  나의 기존모습

  다양한 방법들중이 있는데, 저번에는 이렇게 했으니, 이번에는 이렇게 구현해볼까?

  • 매번 코드 스타일이 달라짐
  • 매번 접근법이 달라짐 ⇒ 이게 개인공부에서는 상관없는데, 회사 코드에서 이러면 고규식 개발자라는 사람의 코드 스타일을 다른사람들이 파악할 수 없음. 코드 스타일이 매번 다름
  • 내가 했어야하는것
    • 각 방법의 장단점을 정리하고 어느 방법이 제일 이상적인지를 찾고 내 기준으로 삼았어야함

  에러에 대한 기준