4주차

이번주 정리

pagevar, let, const 차이 pageDrag & Drop 를 이용해서 리스트 요소 순서 바꾸기 pageUUID

4주차 과제는 솔라커넥트에서 나온 과제였다. 1번째 과제는 정렬 알고리즘을 활용하는 과제였고, 2번째 과제는 어느정도 완성되어 있는 todo-list 에 기능을 추가하는 과제였다.

개인적으로 둘다 재미있었다.

1번째 과제

깃허브 레파지토리 보러가기
배포 사이트 보러가기

해당 과제에서는 타이머, 정렬 알고리즘을 제외한 부분을 구현했다. 흠.. 이렇게 보니 과제의 핵심인 시간과 정렬 알고리즘과는 조금 동떨어진 부분을 맡은거같다.

입력 form
유효성 체크
정렬 결과 필드
로딩 스피너
테스트

전체 구조는 아래처럼 되어있다. 구조가 간단해서 아래 코드만 보면 된다.

export default function SolarApp() {
  const [sorted, setSorted] = useState([]);

  const handleSubmit = value => {
    setSorted(quickSort(value));
  };

  return (
    <SolarAppContainer>
      <Timer format={TIME_FORMAT.KO} />
      <Form handleSubmit={handleSubmit} />
      <ResultFields value={sorted} />
      <Timer format={TIME_FORMAT.EN} />
    </SolarAppContainer>
  );

Form 컨테이너는 입력에 대한 책임을 진다.

ResultFields 는 들어온 입력값에 대한 출력을 담당한다. (ResultFields 하위로 ResultField 가 있다. )

1. 입력 form

form 컴포넌트의 역할은 아래와 같다.

입력을 받을 수 있어야한다.
validation 체크를 할 수 있어야한다.
에러메시지를 보여줄 수 있어야한다.
submit 이벤트가 발동하면 특정 함수를 실행해야한다.

입력을 받을 수 있어야한다.

입력값은 input 에 들어가는 value 로써 form 에서 state 로 관리하게 구현했다.

`validation` 체크를 할 수 있어야한다.

validation 체크에 대해서는 생각을 많이했다. 내가 생각하는 유효하지 않은 입력은 아래와 같다.

숫자가 아닌 문자가 들어오는 경우 (정규표현식으로 가능)
- '-' 가 맨 앞에 오는 경우는 마이너스를 의미하므로 괜찮다.
굉장히 큰 숫자 (또는 굉장히 작은 숫자)
- Number.MAX_SAFE_INTEGER
, 가 연속해서 나오는 경우 (정규표현식으로 가능)
- 1, 2, 3, ,,,, 4, 5, 6,
마지막이 , 로 끝나는 경우 (정규표현식으로 가능)

여기서 1, 3, 4번 같은 경우는 졍규표현식을 사용해서 충분히 해결할 수 있다. 아래의 expression 을 사용하면된다. /(^(\s*-?\d+,)*(\s*-?\d+$))/ . 문제는 2번의 굉장히 큰 숫자다. Number.MAX_SAFE_INTEGER 의 값은 9007199254740991 다. 숫자의 길이를 체크하는거면 상관없지만, 그 범위를 체크하려고 하니 너무 막막해서 포기해버렸다. 따라서 정규표현식을 사용하는게 아니라 입력받은 문자열을 split, map, filter 를 통해 체크하는 방법으로 해결했다. 나중에 정규표현식으로 해결해보고싶다.

그리고 validation 을 언제할건가? 이건 두가지 선택지가 있다.

매번 글자가 들어올 때 마다 validation 검사를 한다.
모든 글자가 들어오고 submit 을 하면 검사를한다. (선택)

1번이 가장 좋겠지만, 문제는 매번 글자가 들어올 때 마다 검사를 하면 입력이 굉장히 길어지는 경우에 성능상에 문제가 생긴다.(다시 생각해보니 debounce 를 사용하면 됐을거같다...) 특히 지금은 유효성체크가 split -> filter -> map -> filter 를 하다보니 더더욱 심하다. 아마 성능좋게 정규표현식으로 구현했으면 어느정도 타협이 가능했겠지만, 그러기에는 시간이 부족했다.

결국 2번째 방법을 선택했다.

에러메시지를 보여줄 수 있어야한다.

에레메시지를 보여주는 방법도 고민을 많이했다. 보여주는 방법에 대한 선택지는 아래와 같다.

input 의 커스텀에러메시지
alert 창을 통해 에러메시지 보여주기
modal 을 구현해서 에레메시지 보여주기
input 창의 아래에 error message 를 보여주기

1번의 경우는 입력할 때 마다 검사를 해야하므로 기각 2번과 3번은 이런 경우에는 사용자 경험이 좋지 않아 기각! 최종적으로 4번을 선택했다.

4번의 경우 에러메시지가 계속 남아있으면 보기 좋지 않다. 따라서 일정 시간 이후에 자동으로 없어지게 구현했다. setTimeout 을 사용했다. setTimeout 을 사용하면 항상 문제가 이전에 실행된 setTimeout 이 남아있을 수 있다는 것이다. 따라서 useEffect 에서 clear하게 구현해줬다.

useEffect(() => {
  if (!errorMessage) return;
  const timer = setTimeout(() => {
    setErrorMessage('');
  }, TIMER.LOADING);
  return () => {
    clearTimeout(timer);
  };
}, [errorMessage]);

아래처럼 일정 시간 이후 에러메시지가 사라지게 된다.

결과필드s (ResultFileds)

결과필드의 역할은 아래와 같다.

정렬되서 들어온 값을 하위 컴포넌트인 ResultField 에 넘겨준다.
역순으로 정렬된 값을 3초뒤에 두번째 ResultField 에 넘겨준다.

역할이 아주 단순하다. 그냥 값을 넘겨주기만 하면 된다. 물론 여기서 함정이 2번인 3초뒤에 건네준다. 3초뒤를 구현하기 위해서 useEffect 를 사용해줬다. Form 때와 마찬가지로 timer 가 남아있는 상황에서 또 실행하게 된다면 clear 하게 만들었다.

useEffect(() => {
  if (!value.length) return;
  setIsLoading(true);

  const timer = setTimeout(() => {
    setReversedValue([...value].reverse());
    setIsLoading(false);
  }, TIMER.POPUP);

  return () => {
    clearTimeout(timer);
  };
}, [value]);

결과필드 (ResulfField)

역할은 인자로 들어온 값을 출력해주면 된다. 만약 로딩중이라면 로딩 컴포넌트를 보여준다.

느낀점

과제는 너무 단순했다. 하지만, 설계하는 과정에서 어떤 형태로 만드는게 가장 좋은 방법인지에 대해 많은 고민을 했다. App 컴포넌트에서 모든 로직을 처리하고 하위 컴포넌트는 단순히 출력값만 보여주게 만들어야 할까? 또는 각 컴포넌트마다 역할과 책임을 부여해서 스스로 state 를 관리하게 만들어야할까?

개인적으로 이번 프로젝트는 뎁스가 적기 때문에 첫번째 방법인 App 컴포넌트에서 모든 로직처리를 담당하고, 하위 컴포넌트에서는 출력만하면 된다고 생각한다.

form 은 정말 입력만 받고 submit 이 발생하면 값을 solarApp 에 보낸다.
solarApp 은 유효성체크를 하고 통과하면 정렬을 한다. (모든 로직을 여기서 처리)
정렬된 값을 결과 필드에 보내준다.
3초 뒤에 두번째 결과필드에 값을 보내준다.

평소라면 이렇게 했겠지만, 이번에는 각 컴포넌트마다 역할을 갖게 만들었다. 이렇게 만들어서 엄청 두꺼워 지는 컴포넌트 없이 각 컴포넌트가 고루 어느정도의 규모를 갖게 됐다. 아직 경험이 일천해서 어떤게 좋은지 아직도 모르겠다.

2번째 과제

깃허브 레파지토리 보러가기
배포 사이트 보러가기

2번 과제는 todo list 를 만드는 과제다. 자바스크립트 공부할 때 구현했던 경험이 있어서 재밌게 진행했다. 솔직히 말하면 css 는 흠.. 이쁘게 만들지 못했다. 그래도 내가 중요하게 생각하는 부분에 대해서는 어느정도 구현했다. 내가 중요하게 생각하는건 당연하다고 생각되는 건 당연히 있어야한다. 다. todo list 에 당연히 있어야하는게 뭘까?

입력을 할 수 있어야한다.
수정할 수 있어야한다.
각 todo 의 순서를 바꿀 수 있어야한다. (드래그 앤 드랍)

이번 과제에서 조금 걸리는게 있는데, 완료 목표일만 만든게 아니라 시작일까지 같이 만든 점이다. 이렇게 만든 이유는 todo 는 오늘 할 일 뿐만 아니라 내일 할일, 모래에 할 일 등 나중에 할 todo 도 만드므로 시작일도 중요하다고 생각했다. 따라서 시작일을 만들게 되었고, RangePicker 를 사용하면서 moment 를 설치하게 되었다. (과제에서는 아무것도 설치하지 말라고 했다.) 그리고 코드 구현도 조금은 엉성한거 같다. 하하하하하...

드래그 앤 드랍

만족하는 점은 드래그 앤 드랍 을 구현했다는거다. 이전부터 한번 구현해보고 싶다라는 생각을 가지고 있었는데, 과제 마무리 하려고 할 때 딱 생각나서 아슬아슬하게 구현했다. 아래 링크에 정리해놨다.

pageDrag & Drop 를 이용해서 리스트 요소 순서 바꾸기

커스텀훅의 형태로 구현했다. 나는 코드를 분리하는걸 좋아한다. 따라서 커스텀훅은 나에게 아주 좋은 도구다. useDragAndDrop 을 커스텀훅으로 만듦으로써 다른 프로젝트를 할 때 조금의 수정만을 통해서 DnD 기능을 사용할 수 있게 되었다.

여기서 궁금하게 있다. 얼마전 유튜브 영상에서 어떤 개발자의 이런 말을 들었다.

나는 예전에 모든 로직을 커스텀훅을 만듦으로써 분리했다. 하지만 요즘 생각은 커스텀훅으로 로직을 분리시키면 코드의 응집성이 나빠지므로 옛날과 다르게 그렇게 만들지 않는다.

그러면 나도 재사용성을 고려하지 않는다면, 커스텀훅으로 로직을 분리하면 안되는건가? 나는 그래도 커스텀훅을 만드는게 좋아보인다. 뭐 경험이 쌓이다 보면 생각이 달라질 수 있겠지

UUID

이번 과제할 때 유일성을 보장해줄 무언가가 필요했다. 왜냐하면 todo 의 id 값을 줄 때 배열의 길이를 기반으로 주는게 문제가 있었기 때문이다. 처음에는 시간을 기반으로 id 를 만드려고 했다. 하지만 엄청 빠른 시간내에 todo 를 만들면 문제가 생길 수도 있겠다라는 생각이 들어서 현재시간 + 랜덤값으로 최종 결정을 했는데... 갑자기 떠오른게 UUID 였다. 솔직히 UUID 가 뭔지 잘 몰랐지만 이게 무적에 가까운 랜덤값을 생성해 줄 수 있다는 사실은 알고 있었다. 따라서 이참에 과제에도 적용하고 새로운 지식도 쌓을겸 정리하고 구현해봤다.

정리는 아래 링크에서 볼 수 있다.

pageUUID

이번주에 배운거

정규표현식을 어느정도 할 수 있게 되었다.

var, let, const 의 차이점에 대해 알게 되었다.

드래그 앤 드랍 을 정리하고 구현했다.

UUID 에 대해 정리했다.

아 그리고 2번째 과제는 타입스크립트로 구현했다. 솔직히 말하면 다른 기능구현에 급급해서 타입스크립트를 타입스크립트 답게 사용하지 못했다! 반성한다.

타입스크립트 처음 사용할 때 이런걸 왜 쓰지 싶었다. 무엇을 하든간에 타입을 지정해주는게 정말 어렵고 귀찮았다.하지만 생각해보면 이렇게 타입을 지정해줌으로 인해서 굉장히 많은 효용을 느낄 수 있다. 이 효용이라는게 팀프로젝트를 할 때만 얻을 수 있는게 아니라 개인프로젝트를 할 때에도 얻을 수 있다. 간단한 예로 vscode 로 프로젝트를 진행할 때 타입스크립트를 사용하면 (원래 자바스크립트로 할 때는 뜨지 않는) 자동 완성이 뜨게 된다. 앞으로의 과제에서 열심히 사용해야겠다.

Previous3주차 Next5주차

Last updated 2 years ago