02_input 성능 개선, 아토믹 디자인 시스템
한것 What I have done
1. 테스트 계정으로 체험하기 토글 추가
개요 포트폴리오로써 보는 관점에서 테스트계정 치고 들어갈 필요 없으니까 편리하다는 피드백 참고
문제상황
input type="checkbox"를 만들어서 바뀌면 email, password상태를 정해진 테스트계정 값으로 바꾸고, 바뀐 상태값을input type="email"input type='password'에 넣어주었는데, 내가 의도한 것과 정확히 반대로 동작하는 것을 발견함해결 방법
useState의 state는 한 번의 렌더링 안에서 const 변수이기 때문에 useEffect로 리렌더링을 유도해야 함
useEffect로 state가 바뀌면 실행될 코드를 분리해서 사용해야함
결과
2. input onChange 리팩토링
개요
리액트 성능 최적화 방법을 알아보다가
당장 적용 가능한 방법 한가지를 발견,
✨당장 적용헤..✨
문제상황
배운 방법:
input 태그에 onChange 함수
타이핑을 할때마다 useState로 값이 바뀌게
문제점: useState로 값이 바뀔때마다 해당 컴포넌트가 리렌더링
해결 방법
이에 대한 최적화 방법은 onChange 대신 onKeyup을 사용
입력 직후에 변수에 입력값을 저장해놨다가,
입력 후 400밀리초 뒤에 useState로 상태를 바꾸기.
예상 결과
상태를 바꾸는 조건이 입력 후 400밀리초 뒤에도 입력값이 바뀌지 않는 것이라서
사용자가 입력을 마쳤다고 간주하면 상태가 바뀌고 그 때에만 리렌더링 됨
결과
3. 아토믹 디자인 시스템 도입 (진행중)
개요:
개선한 인풋 요소를 컴포넌트로 만들면 편할 듯
컴포넌트 어떻게 만들어야될 지 검색
컴포넌트를 만들 때 주의할 것
규칙을 제각각으로 만들면, 관심사가 너무 많거나
재사용이나 확장할 수 없는 컴포넌트가 생기는 문제
아토믹 디자인 - 디자인 시스템 방법론
atom - molecule - organism - Template - page
atom: 더이상 쪼갤 수 없는 단일요소 (ex. 태그, 글꼴, 컬러팔레트, 레이아웃 등)
molecule: 여러 atom을 결합, 고유의 특성을 가짐, 한가지 동작을 함(SRP, Single Responsibility Principle) - 테스트하기 쉽고, 재사용성 높음
organism: 특정 컨텍스트를 가짐, 상대적으로 구체적, 재사용성 낮음 (ex. header)
Template: 컴포넌트를 배치하고 구조를 잡는 와이어프레임, 컨텐츠가 없는 page (스켈레톤)
Page: 유저가 보는, 실제 컨텐츠를 담은 요소, template의 인스턴스라고 볼 수 있음.
주의사항
Molecule vs Organism:
SRP, Single Responsibility Principle을 지킬 수 있느냐
Context가 없어도 컴포넌트의 역할이 설명이 되느냐
그래도 모호하면 일단 Organism
중복 컴포넌트
compound 컴포넌트 (합성 컴포넌트)로 해결하기
UI 제어하는 상태 이런거는 다 외부에서 주입하기 (스토리북 유용)
마진, 패딩과 같은 레이아웃 관련 스타일도 외부에서 주입하기
UI 모델링
하나의 컴포넌트의 단위를 쪼개고 네이밍 하는 과정을 피그잼을 통해 함께 진행하기
4. 기타 버그 픽스
로그인 전에 메뉴 버튼 뜨는 것
menu가 들어갈 때 y포지션이 이상해 지는 것
모바일 화면에서 nav가 튀어 나가는 것
모바일 화면에서 헤더 로고나 로그아웃 텍스트가 사라지게 하는 것
느낀점 및 고민한 부분 What I felt or thought
1. 헤더의 햄버거버튼
헤더의 햄버거 버튼은 헤더내에서만 사용됨. 재사용되지는 않음
하지만 css도 애니메이션 때문에 복잡하고, 코드적으로 따로 컴포넌트를 만들어 주는게 가독성 좋음
이런 것도 컴포넌트라는 것
Last updated