2024.07.28, weekly memoirs

 

 

weekly memoirs

 

 

 

 

 

---

 

 

 

(소중)

 

 

 

 

 

1.

공유 오피스 잘 끊은 거 같다

카페에서 공부할 때와 질이 다름...

원래는 주말마다 따로 카공할 수 있는 자리가 따로 있는 대형 카페 자주 갔었다ㅎㅎ

나쁘진 않았지만 아무래도 대형카페다 보니까 조금 시끄러웠었는데

여기는 조용하고 자리 넓구 밝고... 깨끗하고 모니터 있는 자리도 따로 있고 심지어 커피도 무료다 ㅎㅎ

너무 좋다 ㅎㅎ

 

그리고 다니면서 약간 동기부여가 되는 점도 있는데

주말밖에 안 와봤지만 은근 여기 공유 오피스를 많은 분들이 이용하시는 것 같다...

다들 노트북 앞에서 열심히 일하신다

 

점심 시간 전 후로 오는 편인데 늘 10분 이상은 계신 것 같음...

열심히 사는 사람들이 이렇게나 있다

나두 계속해서 열심히 살아야지

 

 

 

 

2.

어제 자기 전에 이제껏 써왔던 글들을 몇 개 봤는데

은근 틀리게 쓴 것도 많아서 부끄러웠다....(심지어 최신 것도...)

 

공부 -> 실전

이렇게 도입하는 이유는 시간이 없어서이기도 하지만

제대로 알고 써야 의미가 있다고 생각해서 선학습을 먼저 진행했는데(이때 블로그에 글 올림)

실전에 적용하다 보면, 이해했다고 생각했던 것들이 사실은 그렇지 않았음을 깨닫게 되는 경우가 많다

 

이 수순을 몇 번 겪다보니

뭐든 한번에 이해할 수 있는 건 불가능한 일이라는 생각이 들었다

 

큰 틀 먼저 세우고 거기에 살을 붙이는 방향으로 가야하는데

이 과정이 주말에 좀 한다고 해서 되는 건 아닌 거 같음

 

어떤 주제를 이해하는 걸 빈 컵에 채운다고 표현했을 때

 

돌 채우기 -> 자갈 채우기 -> 모래 채우기 => 물 채우기

 

와 같은 순서로 여러 번 반복하는 과정이 필요한 것 같다

그러니까 당황하거나 조급해하지 않고 차분하게 학습해 나가야지

 

 

 

 

3.

요즘 왜 리액트를 써야하는가...에 대한 생각이 좀 더 잡혀지는 것 같다

오로지 사용자의 UX..! 부드러운 UI를 위해서 쓰는 거 같음

화면을 이동했을 때 깜빡이지 않는다거나, 그 사이에 사용자에게 알려줄 수 있는 로딩바를 넣는다거나...

 

리액트는 그 컨셉을 위해서 SPA와 CRA를 사용했고

컴포넌트 단위로 이루어진 것도 개발자가 UI관점에서 작성할 수 있도록 유도했던 게 아닐까? 싶다 (그냥 내 생각 ㅠ)

 

이제껏 왜 리액트를 써야하는가에 대해서 고민을 해왔던 이유는

기존 mpa 구조로 만들어진 페이지보다 느렸기 때문이다

그냥 느린 것도 아니고 많이 느렸음

 

애초에 가상돔에서 연산하는 과정을 한번 거치기 때문에 느릴 수밖에 없지만...

단순한 구조의 페이지는 괜찮은데 복잡한 페이지일수록 너무 느렸다

 

과거에 한 페이지에 기능 엄청 많은 페이지를 진행했을 때... 진짜 가상돔 터질 것 같다는 생각을 자주 했었던 거 같다

(그리고 이때 진짜 크롬 터졌음)

 

그럼 어떻게 하면 리액트로 페이지를 빠르게 만들 수 있을까 생각해봤는데

memo 나 useCallback 최적화도 좋고... suspense 기능도 있지만 

어쨌든 최대한 리렌더링 줄여서 만드는 게 중요한 거 같다

그래야 조금이라도 덜 연산해서 화면을 그리니까...

 

리렌더링을 줄이려면 한 컴포넌트가 많은 기능을 담당하는 게 아니라 

각자 하나의 역할만 할 수 있도록 잘 쪼개어서 리렌더링이 덜 일어날 수 있게 조절하는 게 중요한데

 

이건 곧 컴포넌트 설계의 문제로 넘어가고

설계를 잘 짜려면 페이지의 전체적인 컴포넌트 기준은 무조건 잡고 들어가야한다

 

컴포넌트 기준은 고려해야할 점이 많고 사람마다 다를 것 같은데...

 

일단 내가 처음에 가장 많이 실수 했던 건 무조건 뷰단위로 쪼개려고 했던 것...

뷰 단위로 먼저 쪼개놓으면 나중에 상태 관리할 때 엄청 낭패 본다

props 갯수뿐만 아니라 depth 도 늘어나고...

 

기가 막힌 상태 흐름을 볼 수 있음...

 

때문에 나 같은 경우에는 상태 관리 흐름 + UI 단위의 추상화를 먼저 생각한다

뷰 단위로 쪼개는 건 정말 언제든지 할 수 있는 작업이라서 일단 한 컴포넌트에서 작업하면서 설계를 잡아가는 편이다

 

리액트 잘 하시는 분들은 처음부터 딱딱 나눠서 사용하실 것 같은데

아직 나는 atom 단위말고는... 처음부터 못 잡겠움...

 

얼추 상태 흐름 보면서 여기는 모달이 나올거니까 여기에서 상태 처리하자~ 하는 생각으로 짜긴 하는데

이렇게 공 들인다고 해도 꼭 props 한 두개씩은 늘어나는 것 같다 ㅎㅎ

 

아무튼 이렇듯 리액트는 참 고려해야하는 게 많은 툴인 거 같다

제이쿼리 썼을 땐 html 그릴 때 돔 구조 신경 쓰거나 기능들 함수로 빼는 것 말고는 크게 신경쓰진 않았던 것 같은데...

 

훨씬 쉽고 간단한 제이쿼리, 자바스크립트가 있는데 왜 신경 많이 써도 느린 리액트를 써야하는가? 오직 ux를 위해서..?

라고 했을 땐 솔직히 잘 모르겠다

 

라이브러리도 필요하면 쓰고, 아니면 그냥 구현해서 쓰듯이 서비스에 맞게 쓰는게 중요한 것 같음

리액트 잘 못해서 그런 거 아니냐고 하면 할말 없지만,,,,,,,,,

 

 

암튼 이제 리액트에 대한 고민은 끝났다

이제 다시 next.js 고민해야지ㅎ

 

 

 

 

4.

요즘 타입스크립트 공부한다.

나름 재밌다

 

근데 타입스크립트 안에서도 타입 연산해서 쓰길래

공부하다가 이러면 느려지는 거 아닌가? 싶었는데

생각해보니까 어차피 타입 체크할 때나 좀 느려지고 빌드 때 자바스크립트로 바꿔서 브라우저 내보내는 거니까... 

전혀 상관 없을 거 같다

 

암튼 공부하니까 좀 더 멋지게(?) 타입을 쓸 수 있는 거 같아서 좋은 거 같다

 

 

 

 

5.

남은 7월 파이팅!!!!!!!!!!!!!!!!!!!