아래 사례들을 교육을 통해 잘 숙지하게 된다면 → 말이 통하는 사람이 될거 같다(동료 가능)
•
객체지향 자료들이 프론트엔드 자료들이랑 다르다고 느껴질 수 있지만 → 본질적으로 보면 똑같이 적용할 수 있다 → 그걸 깨달은 다음에는 객체지향 자료들을 봐도 이해가 됨
◦
‘클래스 인스턴스’에서 초기값 갖는 것과 → ‘리액트 컴포넌트’ 내부 상태를 갖는 것에는 거의 차이가 없다
◦
자바 진영에서 전역 싱글톤 만들지 마라 → 리액트에서 전역 상태 만들지 마라는 것과 거의 차이가 없다
◦
지켜야 하는 원칙은 같고 코드의 형상이 다르다.
•
백엔드에서 그냥 동기 로직을 짜다가 → 동시성을 다루게 되면 뭐 예를 들면 트랜잭션이냐, 분산락이나, 여러 인스턴스간 환경, 스레드, … → 세마포어, 뮤텍스 등의 동시성 관련 개념을 배우게 되고
◦
그 개념을 가지고 ‘시간’과 ‘동시성’을 다룰 수 있게 되는데
◦
프론트엔드 개발자들은 이런 개념 모델을 대체로 잘 학습하지 못함에도 불구하고 항상 ‘시간’을 다루고 있음 → 여기서 슬픔이 만들어진다
▪
ex. 이벤트 기반, 비동기 렌더링(Suspense, Transition, …), Promise 이벤트 루프, …
•
useEffect의 감지 모델이 아니라 이벤트 핸들러의 액션 모델로 생각하면 쉽게 풀리는 것들이 있음
◦
ex. onSubmit을 useEffect로 쓰지 않고 Form의 onSubmit으로 작성하기
•
0 or 1?
◦
추상화를 정말 잘했다
◦
추상화를 평범하게 했다 → 오히려 안좋았던 경험들이 있음
▪
ex. context api로 의존성 주입 → 사용처의 복잡도를 줄였지만, 그 복잡도가 분리된 Context 쪽의 코드가 너무 많이 늘어나서 복잡해졌다
•
context api의 보일러플레이트 코드가 너무 많다
◦
아 그러니까 zustand 쓰자 → 뚝배기! → 왜냐하면 이 둘은 시맨틱이 다름 (전역 상태 vs 범위 한정하여 의존성 주입) → 차라리 zustand-di를 쓰는게 맞음 → 내가 필요한게 context api냐 zustand냐가 아니라 의존성 주입이다 라는걸 알아봐야 함.
•
→ react compiler, use 등이 오기 전까지 땜빵을 치는 과정. 그 과정에서 이게 왜 필요한지 알아보고, 어떤 시퀀스로 최종 단계로 나아가면 되는지를 알아보는 사람을 키우고 싶다.
◦
추상화를 안했다
상태 원천 → 레포지토리 (인메모리, URL, 로컬 스토리지, 서버 상태)
•
리포지토리 레이어로 프론트엔드 상태들을 추상화하고 싶어도 실행 환경이나 플랫폼의 다양한 특성들을 알고 쓸 수 밖에 없는 문제가 있음
◦
예를 들면, URL은 히스토리 API에 접근할 수 있는 환경이어야 하고
◦
로컬 스토리지는 브라우저여야 하고
◦
서버 API라면 Suspense를 쓸지 말지 등을 판단해야 함
•
그래서 리포지토리로 그냥 땡하고 묶어버리면 사용처에서 벼락을 맞을 수도 있음. → 그래서 리포지토리 레이어로 추상화 하지 않겠음 이라는 판단을 했음.
•
하지만 그래도 이 문제점을 인식하고 다양한 대안을 떠올려볼 수 있다는 점이 합리적이므로 좋은 사례
데우스 mobx → fine-grained reactivity를 사용한 사례
•
일부 유지보수성이나 컴포넌트 인터페이스를 통한 예측 가능성은 떨어졌지만
•
렌더링 성능이 가장 중요한 프로젝트이므로 이런 부분을 일부 트레이드 오프 하는 선택을 했음
•
이 판단 자체는 아무런 문제가 없음. 하지만 leaf node에 있는 컴포넌트에 숨겨진 암묵적 의존성의 위험성을 알고 쓰는 사람과 모르고 쓰는 사람 사이에는 너무 큰 차이가 있음. 대부분 이 의존성을 알아보지 못하는게 너무 큰 문제 상황임.
문제: 지식을 알고 있지만 → 내가 써야 하는 코드가 크게 바뀌지 않았다 (나의 역량 혹은 경험 문제일 수도, 혹은 프론트엔드 생태계의 미성숙 때문일 수도 있다)
•
리액트 useMemo, useCallback 맨날 이렇게 불행하게 써야 해? → 어쩔 수 없어
◦
일 수도 있고 → 아 이거 우리가 비즈니스 로직 작성하는 쪽에서 신경써야 할 관심사가 아닌데?
◦
그러면 좀 더 상위 레이어에서 해결해줘야만 해(라는 확신을 얻을 수 있다. 왜냐하면 소프트웨어 엔지니어링 일반적인 역사를 봤을 때, 원리상 그러함) → 이거를 해결한 다른 사례들을 떠올려보면
◦
컴파일러 → 그러면 컴파일 타임에 정적분석(리액트 관련 로컬 룰)을 통해서 리액트 코드를 최적화 시켜주는 책임을 담당하게 하자
◦
아! 그러면 리액트 컴파일러가 있어야겠네 (Best Practice를 먼저 생각해본다)
◦
(그걸 바로 못쓴다면) 이 리액트 컴파일러가 나오기 전까지 어떤 workaround를 적용해볼 수 있을까? 같은 혹은 비슷한 효과를 내는 리액트 컴파일러보다는 조금더 구체레벨에 가까운 레이어에서 해볼 수 있는게 있을까?
◦
(작은 추상화를 반복 → 쌓아올려서 점진적으로 나아가다 보면 최종적으로 best practice를 적용하게 됨)
