blog

당장복습헤! 성능 개선부터 아토믹 디자인 시스템까지

한것 What I have done

1. 테스트 계정으로 체험하기 토글 추가

  1. 개요 포트폴리오로써 보는 관점에서 테스트계정 치고 들어갈 필요 없으니까 편리하다는 피드백 참고
  2. 문제상황 input type="checkbox"를 만들어서 바뀌면 email, password상태를 정해진 테스트계정 값으로 바꾸고, 바뀐 상태값을 input type="email" input type='password'에 넣어주었는데, 내가 의도한 것과 정확히 반대로 동작하는 것을 발견함
  3. 해결 방법
    1. useState는 비동기라서 바로 반영이 되지 않았음을 발견
    2. useEffect로 state가 바뀌면 실행될 코드를 분리해서 사용해야함
  4. 결과
As-is To-be
toggle+as-is toggle+to-be
스크린샷 2023-12-06 오전 9 30 55 스크린샷 2023-12-06 오전 9 32 35

2. input onChange 리팩토링

  1. 개요
    1. 리액트 성능 최적화 방법을 알아보다가
    2. 당장 적용 가능한 방법 한가지를 발견,
    3. ✨당장 적용헤..✨
  2. 문제상황
    1. 배운 방법:
      1. input 태그에 onChange 함수
      2. 타이핑을 할때마다 useState로 값이 바뀌게
    2. 문제점: useState로 값이 바뀔때마다 해당 컴포넌트가 리렌더링
  3. 해결 방법
    1. 이에 대한 최적화 방법은 onChange 대신 onKeyup을 사용
    2. 입력 직후에 변수에 입력값을 저장해놨다가,
    3. 입력 후 400밀리초 뒤에 useState로 상태를 바꾸기.
  4. 예상 결과
    1. 상태를 바꾸는 조건이 입력 후 400밀리초 뒤에도 입력값이 바뀌지 않는 것이라서
    2. 사용자가 입력을 마쳤다고 간주하면 상태가 바뀌고 그 때에만 리렌더링 됨
  5. 결과

| As-is | To-be | |—|—| |as-is|to-be| |image| image|

3. 아토믹 디자인 시스템 도입 (진행중)

  1. 개요:
    1. 개선한 인풋 요소를 컴포넌트로 만들면 편할 듯
    2. 컴포넌트 어떻게 만들어야될 지 검색
  2. 컴포넌트를 만들 때 주의할 것
    1. 규칙을 제각각으로 만들면, 관심사가 너무 많거나
    2. 재사용이나 확장할 수 없는 컴포넌트가 생기는 문제
  3. 아토믹 디자인 - 디자인 시스템 방법론
    1. atom - molecule - organism - Template - page
    2. atom: 더이상 쪼갤 수 없는 단일요소 (ex. 태그, 글꼴, 컬러팔레트, 레이아웃 등)
    3. molecule: 여러 atom을 결합, 고유의 특성을 가짐, 한가지 동작을 함(SRP, Single Responsibility Principle) - 테스트하기 쉽고, 재사용성 높음
    4. organism: 특정 컨텍스트를 가짐, 상대적으로 구체적, 재사용성 낮음 (ex. header)
    5. Template: 컴포넌트를 배치하고 구조를 잡는 와이어프레임, 컨텐츠가 없는 page (스켈레톤)
    6. Page: 유저가 보는, 실제 컨텐츠를 담은 요소, template의 인스턴스라고 볼 수 있음.
  4. 주의사항
    1. Molecule vs Organism:
      1. SRP, Single Responsibility Principle을 지킬 수 있느냐
      2. Context가 없어도 컴포넌트의 역할이 설명이 되느냐
      3. 그래도 모호하면 일단 Organism
    2. 중복 컴포넌트
      1. compound 컴포넌트 (합성 컴포넌트)로 해결하기
      2. UI 제어하는 상태 이런거는 다 외부에서 주입하기 (스토리북 유용)
      3. 마진, 패딩과 같은 레이아웃 관련 스타일도 외부에서 주입하기
    3. UI 모델링
      1. 하나의 컴포넌트의 단위를 쪼개고 네이밍 하는 과정을 피그잼을 통해 함께 진행하기

        4. 기타 버그 픽스

  5. 로그인 전에 메뉴 버튼 뜨는 것
  6. menu가 들어갈 때 y포지션이 이상해 지는 것
  7. 모바일 화면에서 nav가 튀어 나가는 것
  8. 모바일 화면에서 헤더 로고나 로그아웃 텍스트가 사라지게 하는 것

    느낀점 및 고민한 부분 What I felt or thought

    1. 헤더의 햄버거버튼

  9. 헤더의 햄버거 버튼은 헤더내에서만 사용됨. 재사용되지는 않음
  10. 하지만 css도 애니메이션 때문에 복잡하고, 코드적으로 따로 컴포넌트를 만들어 주는게 가독성 좋음
  11. 이런 것도 컴포넌트라는 것

    2. 디자인 때도 못하던 디자인 시스템 구축하기 개발로 할 수 있겠냐?

  12. 스스로에 대한 의심
    1. 개발을 더 잘하려고 보니 디자인으로 다시 회귀했다.
    2. 디자인을 전공하고서도 못한 걸 이제와서 시작한 개발로 할 수 있겠냐는 의구심
    3. 디자인보다 복잡하고 규칙이 없는 건 아닐까?

    4. ‘마땅히 정해진 규칙은 업지만 갈수록 복잡성은 커져갑니다. 빠르게 변하는 기술이 프론트엔드 개발을 어렵게 만든다는 건 이제 새삼스럽지도 않습니다. 프론트는 기획과 디자인 백엔드와 인프라 등 모든 방법과 기술을 조합한 결과가 보여지는 곳입니다.’ - 출처: «프론트엔드 아키텍처: 컴포넌트를 분리하는 기준과 방법», 이문기

  13. 반박하기
    1. 아니다 댕모험때, 코다트 때, 디자인 시스템 구축 해봤다.
    2. 디자인 시스템 만들기 싫어서 디자인 고만둔거 아님.
    3. 아이디어를 내고 개선사항이 생겼거나
    4. 어떤 방법론이 있어서 적용해봤는데
    5. 이걸 반영하고 효과를 확인하기 까지 너무 오래걸렸음.
    6. 반면에 프론트엔드 개발은 방법을 찾고 적용을 하면,
    7. 리렌더링 횟수 감소! 실행속도 단축! 등의 효과를 바로바로 확인할 수 있음

      앞으로 할 일 What I have to do from now on

      1. 디자인 시스템 도입을 위해 피그마로 돌아가보자

      특이사항 miscellaneous

      • .