java, c ++ 같은 엄격한 언어들을 다루다가 javascript로 넘어왔을때 가장 이질적이었던 문법이 바로 구조 분해 할당이다.
const array = [1, 2, 3];
const [a, b, c] = array;
console.log(a, b, c); // 1 2 3
사실 이런식으로 할당하는 상상을 안해본 것도 아니고 논리적으로 이해가 안가는 것도 아닌데 막상 진짜 된다고 하니까 이질적인 느낌이 많이 들었다. 그래서 실전 코드 작성시에는 잘 쓰지 않았었다가 알고리즘 문제를 풀때서야 필요성을 느끼고 사용 했던 기억이 난다.
Tanstack-Query (React-Query)
// 오늘 캐싱을 위해 작성했던 react-query문
const { data, isLoading, error } = useQuery<LeaderboardData, Error>({
queryKey: ["teamrank"],
queryFn: fetchLeaderboard,
staleTime: 60000,
gcTime: 3600000,
});
사실 지난번 프로젝트에 react-query(tanstack-query라고 해야하는지 너무 헷갈린다.)를 사용하긴 했지만 작동 구조를 익히는데에도 버거웠어서 문법 자체를 자세히 들여다 본 적은 없었는데 오늘 쿼리문을 작성하면서 문득 " 어 ? 이거 비구조화 할당이구나 ? " 라는 생각이 들었다. 글로 표현을 다 할 수 없을 뭔가 깨달음의 벽을 하나 넘은 느낌이 들었다. 비슷한 경험으로는 프로그래밍 씬에서 정말 많이 사용되는 객체 라는 용어를 이해했을때였는데 이번에 비슷한 느낌을 받았다.
사실 그동안 react-query를 캐싱기능만 사용했고 그저 queryFn에 의존성을 가진 기능이라고 생각을 했는데 구조가 눈에 들어오니 전체적인 구조가 이해가 가기 시작했다. 나는 어떠한 개념을 이해했을때 그것을 간략히 정리해 GPT에게 내가 이해한 것이 맞는지 확인을 하는 습관이 있다. 그때 네. 맞습니다 라는 대답이 오면 뭔가 인정 받은 것 같아 기분이 좋은데 이번에도 비슷한 경험을 했다.
이번 프로젝트는 ui/ux에 신경을 많이 쏟고 있다. 저번 프로젝트에서 가장 부족한 부분이기도 했고, 부하테스트 기반 성능테스트를 아무리 고퀄리티로 한다고 해도 유저들은 당장 자신들의 눈에 보이는 ui/ux의 변화에 더 민감하게 반응한다는 것을 깨달았다. 그래서 앞서 말한 react-query의 구조를 깨달은 것과 연결짓자면 이번에는 data 뿐만 아니라 isLoading과 error를 좀 잘 활용해보려 한다. 로딩 시간이 짧은 것이 물론 제일 좋지만 피치 못할 사정으로 로딩이 길어졌을때 혹은 에러가 떳을 때 ui/ux가 망가지는 것 만큼 허접해보이는게 없더라. 이 부분을 잘 개선해서 최소한 허접해보이지는 않는 프로젝트를 만들어보고싶다.
주절주절
배포하는 그 날 까지 아니, 배포 한 후에도 YOUR.LOL 제작기 시리즈는 매일 연재하는 것을 목표로 할 것인데, 오늘과 같이 개념적으로 무언가를 크게 배웠다고 느낀날은 이런식으로 개념 중심의 글을 작성 할 것이고 그렇지 않은 낳은 그 날 개발 한 것을 위주로 개발일지를 작성 할 것 같다. 어차피 그 날 한 것들은 커밋 로그에 잘 남아있으니 말이다.
커밋 로그 이야기가 나와서 생각이 났는데, 요즘 무지성으로 git add . 를 하지 않고 한 파일 한 파일마다 add를 해가며 commit을 하고 있는데 보통 이렇게 하는게 맞는 방법인지가 궁금하다. 사실 제일 좋은 것은무언가를 했을때마다 꾸준히 기록하는 것인데 정신 없이 코드를 치다 보면 까먹을 때가 좀 있어서 이렇게 보완을 하고 있는데 잘 하고 있는 건지 모르겠다.
Ghost