왜 또 10월 끝남

• 그렇게 11월이 끝남

새로운 기술을 쓴다는 것이 기술적으로 성장했다는것을 의미하지 않는다

레몬베이스 엔지니어의 더하기에서 곱하기로 가는 여정

• 성과 측정, 문제 해결 관련하여
  • 개인보다는 팀이 함께
  • 높은 가치를 얻기 위해 협업
• 이 내용도 같은 흐름이다
• 개인의 성장을 너머 팀의 성장이 주는 가치

Esbuild 기반 React Native 번들러 개발기

• 토스에서 직접 번들러를 구현했다는 소식은 들었는데
• 이렇게 개인이 구현한 내용을 공유한 것은 처음인듯하다
• 감탄뿐
• metro가 갖고 있는 문제점들은 해결하여
• 개발경험을 끌어올리는 것인데
• 이는 결과물에는 큰 영향을 주지 못하기에 관심을 가지지 않을 수 있는데
• 이렇게 깊게 파고 드는 것에 다시 또 감탄

하나하나 뜯어보다가

• IoC 합성 컴포넌트 패턴으로 되어있어 구조를 파악하는데 생각보다 어려웠다
• 이미 구현된 것을 사용하는 것에는 어려움이 없지만 (사용법만 잘 따라하면)
• 이를 리팩터링 하는것은 낮은 이해도만으로는 쉽지 않았다 (내가 이해를 잘 못했기 때문이다)
• 양방향 통신을 꺼려하는 이유는 어디서 언제 누가 업데이트 했는지 찾기 어려움이라고 생각하는데 (반면 어디서든 업데이트 할 수 있기에 좋다고 생각했다)
• 합성 컴포넌트는 이때의 경험과 동일했다
• 구조만 따르면 언제 어디서든 접근할 수 있었지만 이에 따른 부작용은 너무나 컸다
• 잠깐만 이게 합성컴포넌트가 아닌가?? 제어역전이 맞나 😱

해커톤

• 우리 서비스의 어떤 문제를 풀어낸다면 더 좋은 서비스를 줄 수 있을까를 생각하기보다
• 단순히 무언가 새로운것을 만들어보고 싶다 라는 쪽으로 너무 치우쳐있었다
• 그렇기에 문제를 해결하는 것에 대한 것보다 재미있어보이는 것을 우선으로 보았다
• 이것이 지금 돌아보면 아쉽다
  • 같이 볼 수 있었고 조금 더 적극적으로 고민했더라면
• 내가 쓰고 있는 제품, 서비스를 위한 일을 한다면 좋겠다

뿐만아니라

• 목표만 지향하다보면 목표를 이루지 못했을때 지치게 되는데
• 그 과정에서 겪을 수 있는 시스템에 대한 경험을 하는 것에 의의를 둔다면
• 결과만 바라보는 것이 아닌 과정에서 얻을 수 있는 무언가

오픈소스답게 소프트웨어 설계하기

• 마인드셋에 대한 내용을 적어둔다
• 오픈소스로 세상에 내보내기 전에 완벽한 것을 작성하고 내보내야한다는 생각이 들기 마련인데
• 하지만 오픈소스란 단순히 하나의 배포 방식이라고 생각한다면
• 오픈된 다양한 피드백을 받을 수 있는 장소일뿐

(번역) 이상한 자바스크립트: 왜 every()는 빈 배열에 true를 반환할까?

• 내용이 어렵게 느껴지지만 내가 이해하는 방향은
• 조금 더 연산을 최적화 하는 것에 중점을 두는 것이다
• every의 최적화된 연산은 가장 빠르게 false를 반환하는 것이다
• 그렇기에 배열을 순환하면서 falsy를 찾는것에 목적이 있기 때문에 빈 배열은 항상 true 이다

[번역] useEffect는 종종 페인트(paint) 이전에 동작합니다.

• useLayoutEffect로 페인트 이전에 그리도록 의도했다
• 그러나 여기에서 상태를 업데이트 하는 경우
• useEffect도 페인트 이전에 동작하고
• 만약 비용이 큰 상황이였다면 무척 오래 걸리는 페인트가 되겠다
• 업데이트 후 동작하는 useEffect에 의존하지 마세요
  • useEffect가 페인트 이후에 호출되는 것을 보장할 수 없다
  • 사용자에게 한 프레임 동안 그려진 무언가를 보여주고 싶다면 useEffect가 아닌 requestAnimationFrame을 두 번 시도하거나 postMessage 트릭을 사용하세요.
• 레이아웃 이펙트를 분할하는 데 시간을 낭비하지 마세요.
  • 디펜던시를 걸어서 useEffect를 딜레이 시키고 관리하는것보다
  • 모든 크기 추적 로직을 단일 layoutEffect에 남겨두는 것이 더 안전하고 깔끔하며, 사전 페인트 작업의 양이 동일하고, 리액트가 관리해야 할 이펙트가 줄어드는 더 좋은 방법입니다.
• 페인트 → 마운트
  • 위에서 페인트라고 쓰고 있는 것을 마운트로 바꿔서 써본다

Promise는 왜 취소가 안 될까?

• 방법이 있나? 없나

(번역) 시그널(Signal)에 대한 소개

• 전역 상태 리렌더를 최소화 하기 위해
  • 컨텍스트를 제거하고 쿼리 캐시 옵저버를 쓰는 등 여러 시도를 했는데
  • 마지막에는 reanimated의 useSharedValue를 사용해 전달하였고
  • 사용처에서 직접 useDerivedValue로 지역 상태로 바꾸어 사용하였다
• 지난번에도 이 시그널이 보내는 시그널에 오잉 했었는데 다시 한번 오잉 해본다
  • 이걸로 전역 상태를 대체한다면 수많은 뎁스를 거쳐 리렌더 되는 것들을 방지할 수 있을텐데
• 또는 컨텍스트에 animatedRef나 시그널을 넣어두고 값을 직접 변경한다면 그것도 좋을듯하다
  • 물론 양방향 통신이 되어버린다면 조금 복잡해질수도 있지만
  • 내부 구현으로 막으면 되지 않을까