최근 주변을 통해 셀프 브랜딩을 통해 인지도를 높인 개발자들의 구설수를 듣게 되었다. 사실 예전부터 그런 생각은 있었다. '저 정도로 인지도를 높일만큼 대외 활동에 진심인 사람이 회사에서도 높은 평가를 받으며 퍼포먼스를 낼 수 있을까? 물리적으로? 너무 힘들지 않나?' 솔직히 '회사에서의 퍼포먼스도 못 내면서 셀프 브랜딩을 하는 게 문제'라는 생각은 결코 아니다. 이 부분은 스스로의 가치 판단과 선택과 집중의 영역이라고 생각한다. 브랜딩, 마케팅도 능력이고 그것을 통해서 몸값을 높이는 방법도 하나의 길이라고 생각한다. 다만 함께 일하는 동료들의 시선에서는 그러한 행동들이 썩 곱게 보이지 않을 것 같다는 생각이 들었다. 일반적으로 셀프 브랜딩을 하는 대외 활동들을 주변에서는 '잘난 척'이라고 생각하기 쉬운..

동일한 코드 사용 import { useEffect, useLayoutEffect, useState } from "react"; export default function App() { const [a, setA] = useState(0); useEffect(() => { setA((a) => { console.log("first useEffect = " + a + "->" + 1); return 1; }); }, []); useEffect(() => { if (a === 2) { setA((a) => { console.log("secont useEffect = " + a + "->" + 3); return 3; }); } }, [a]); useLayoutEffect(() => { setA((a) => ..

얼마 전, 회사에서 흥미로운 디버깅 이슈가 있었다. 우리 팀에서는 프로젝트 내부에서 사용하기 위해 여러 커스텀 훅을 만들어 재사용하고 있는데, 그중 레이아웃을 감지해서 특정 로직을 실행시킬 수 있는 훅이 존재한다. 이 훅은 useEffect훅을 사용하여 유사한 인터페이스를 확장한 커스텀 훅으로, window.innerWidth 감지를 통해 레이아웃을 알려주는 역할을 한다. 간소화해서 윤곽만 나타내면 대충 아래와 같은 형태로 구현되어 있다. (throttle 등은 생략) const useDisplayDetectEffect = (effect: Effect, deps: Deps) => { const callback = useCallback(effect, deps); useEffect(() => { const ..

뜬금없이 궁금해졌다 자바스크립트에서 종료 조건이 없는 재귀 함수를 호출하면 Maximum call stack size exceeded 에러가 발생한다. 그렇다면 호출 가능한 최대 콜스택은 얼마나 될까? 간단한 코드로 확인이 가능하다. 참고로 꼬리물기 최적화를 적용하면 무한루프가 돌아버리기 때문에 아래와 같은 형태로 호출해야만 한다. function getMaxCallStackSize() { try { return 1 + getMaxCallStackSize(); } catch (e) { // Maximum call stack size exceeded return 1; } } getMaxCallStackSize(); 간단한 js 런타임을 제공하는 runJS 내에서는 9078 크롬 브라우저 콘솔에서는 9157..

2015년. 리액트의 아부지 Dan Abramov는 Container / Presentational 두 가지의 구분을 통해 컴포넌트를 작성하는 패턴에 대해 글을 작성했다. 4년 후인 2019년. 그는 사람들이 자신이 소개한 패턴에 얽매여 맹목적으로 사용하는 것을 보며 깊은 현타가 왔고, hooks를 사용하면 렌더링과 상태 관리에 대한 분리가 가능하기 때문에 더 이상 이 패턴을 권장하지 않는다는 글을 남겼다. 그가 이야기한 컨테이너와 프레젠테이션 컴포넌트의 구분은 사실 세부 구현보다도 목적성에 의해 잘 드러난다. 프레젠테이션 컴포넌트 UI를 표현하는 것을 목적으로 함 상태가 없거나 극히 제한적 순수 컴포넌트(사이드 이펙트가 없는 순수 함수)를 지향 컨테이너 컴포넌트 로직을 관리하는 것을 목적으로 함 상..

파트 리더분이 읽고 내용이 좋다고 공유해주신 책이다. 읽은지는 좀 되었는데, 정말 재미있고 유익하게 읽었다. 1. 왜 내 코드가 유지보수하기 어려워지는 것인지 2. 함수형 함수형 하면서 Pipe 쓰고 map 돌리는게 함수형이 아니라는 것 3. 코드에서 사이드 이펙트를 일으키는 액션을 제거하지 못했기 때문에 테스트 코드를 쓰는게 이렇게 어렵구나 라는 것 위 3가지 외에도 많은 깨달음을 준 책이다. 사실 [액션, 계산, 데이터] 3개의 개념만 숙지하면 이 책은 돈값을 10배 정도 한다. 이해하기도 쉽고, 코드 예시도 너무 어렵지 않게 나와있어서 좋았다. 개인적으로 책에 있는 코드 읽는게 너무너무너무 힘들어서(문법 하이라이트 기능좀...) 거의 안 읽는 편인데 예제들이 다 짧으면서도 중요한 내용이 있어 그나마..