[슬랙 클론코딩] 5주차 회고록

jung moon chai·2022년 11월 7일

제로초 슬랙 클론코딩 타임어택 1기

목록 보기

5/8

1. 버그 수정

1-1. typescript의 커스텀 훅스 타입 수정

지난 2주차 수업에서 useInput 이라는 커스텀 훅스를 만들었었는데 value로 제네릭을 활용해 타입을 들어온 value값과 리턴하는 값의 타입이 같도록 해서 any보다 좀 더 안정성 있게 만들었었는데 그래도 애니타입이 있는 부분들을 수정했다.

import { Dispatch, SetStateAction, useCallback, useState, ChangeEvent } from 'react';

type ReturnTypes<T> = [T, (e: ChangeEvent<HTMLInputElement>) => void, Dispatch<SetStateAction<T>>];

const useInput = <T>(initialData: T): ReturnTypes<T> => {
  const [value, setValue] = useState(initialData);
  const handler = useCallback((e: ChangeEvent<HTMLInputElement>) => {
    setValue(e.target.value as unknown as T);
  }, []);
  return [value, handler, setValue];
};

export default useInput;

handler의 매개변수의 타입을 any로 지정했던 타입을 리액트에서 제공하는 ChangeEvent타입으로 지정해 주었으나, 그것만 지정해 주면 setValue에도 제네릭 T의 타입이 지정되야 한다는 에러가 발생한다. 그렇기 때문에 강제로 타입을 변경 해 주었다. 물론 이 방법도 완벽한 해결책이 될 수 없기에 좀 더 구글링을 해보자.

2. 타입점검 (타입가드)

function a = (b: number | number[]) {
	b.toFixed() // 에러발생: b의 타입이 number뿐만 아니라 array일 수 도 있기 때문
  	if (typeof a === 'number') { // 타입이 number일 경우에만 소수점 처리
    	b.toFixed();
    }
  	
  	b.foreach(() => {...}) // 에러발생: b의 타입이 array일뿐 아니라 number일 수 도 있기 때문
    if (Array.isArray(b)) { // 타입이 배열일 경우에만 반복문 처리
    	b.foreach(() => {...}) 
    }
}

3. 용량 체크 (webpack-bundle-analyzer)

배포모드와 개발모드에서 현재 빌드된 파일의 크기를 체크해서 조금 더 최적화 할 수 있도록 도와주는 라이브러리다.

// 개발모드: 파일의 용량을 html파일로 직접 띄워주도록 설정
config.plugins.push(new BundleAnalyzerPlugin({ analyzerMode: 'server', openAnalyzer: true }));
// 배포모드: 파일의 사용량을 html파일로 저장
config.plugins.push(new BundleAnalyzerPlugin({ analyzerMode: 'static' }));

4. drag & drop 이벤트

onDragOver : 마우스를 드래그 하는 중에 실행되는 이벤트
onDrop : 마우스 드래그를 놓을때 실행되는 이벤트

드랍 이벤트시에 파일을 드래그해서 끌었다면 event.dataTransfer 안에 파일들이 들어가 있는데
브라우저 별로 담기는 객체명이 달라 반드시 분기처리를 해주어야 한다.

const onDrap = useCallback((event) => {
	event.preventDefault();
  	// 분기처리
  	if (event.dataTransfer.items) {...}
    if (event.dataTransfer.files) {...}
});

5. 안 읽은 메세지 표시

모든 채널 및 DM에 접근 했을 때 내가 접근 한 시점을 어딘가에 저장을 해두고 메세지가 채널 및 DM리스트가 왔을때 내가 접근한 시점 이후에 온 메세지들을 카운팅해서 보여 줘야 하는데 내가 어디에 언제 접근했는가를 저장 할 공간이 필요하다. 서버에 저장 할 수 도 있지만, 프론트에서도 로컬 스토리지라는 저장공간이 있기에 로컬스토리지에 내가 채널 및 DM에 입장시, 그리고 모든 행동에 접근 위치와 시간을 저장 하고, 채널 및 DM리스트를 불러 올때 카운팅하는 api로 내가 접근 한 위치와 시간을 보내어 그 위치에서 시간 이후에 온 메세지들의 카운팅을 받아서 출력해준다.
접근 이외에도 모든 행동에 저장을 해야하는 이유는 접근시에만 저장을 하게 되면 그 이후의 내가 한 행동에 대한 액션들이 자동으로 카운트 되지 않기 때문이다.

* 기타

1. in

const a = [1,2,3,4,5,6];
console.log(6 in a) // false
console.log(4 in a) // true

const b = {
    test: 1,
    test2 : 2
}
console.log('test' in b); // true
console.log('test2' in b); // false

객체 혹은 배열에 값이 포함되어 있는지 확인

Optimistic UI의 주의할점

optimistic ui를 적용 하게 되면 서버에 반영 되기 전에 ui에 먼저 적용이 되는데, 인터넷이 느린 환경에서 실제로 누가 먼저 작성 했는가 에 대한 문제가 발생 할 수 있다.

예시
0초 A사용자 : 하이 B (optimistic ui)
1초 B사용자 : 하이 A
2초 A사용자 : 하이 B (서버 반영)

B사용자 화면
B사용자 : 하이 A
A사용자 : 하이 B (서버 반영)

A사용자 화면
A사용자 : 하이 B
B사용자 : 하이 A (서버 반영)

예시 처럼 먼저 작성한 사람의 순서가 뒤바뀌게 보일 수 있다.
그렇기 때문에 DM을 작성한 후에 API호출을 하고 반드시 revealidate를 해주어아만 optimistic ui가 적용 되어 늦게 작성한사람의 글이 먼저 보이더라도 revealidate후에 재정렬 해준다.