프로그래밍 메모장

개발하다보면 로직을 재사용하기 위해 Provider를 사용하는 경우가 있는데,동일한 Provider가 여러번 재사용 되는 경우 (테이블 안에 테이블이 있다던가.. 모달 에서 모달을 연다던가)상태 핸들링에 어려움을 겪었습니다. 그래서 Radix-Ui에서 사용하는 스코프 개념을 본따 라이브러리도 만들었는데,홍보 겸 블로그 글을 작성하려고 합니다 스코프란?import { Dialog } from "radix-ui";// Radix Ui 예시 코드, Root (Provider)를 기반으로 내부에서 상태를 공유해 사용합니다.export default () => ( );Radix UI는 React 기반의 UI 컴포넌트 라이브러리로, Compound Componen..

next14로 사이드 프로젝트를 진행중인데, next14에서 빠른 로딩 및 UX를 위해서 treeshaking을 어떻게 하면 잘 할수 있는지 찾아봤고 요약해 공유한다. 1. next는 페이지 기반 code split을 자동으로 해준다. production 모드에서 확인 가능 2. next는 webpack 기반이다. next에서 babel 대신 swc 기반으로 동작한다. 3. 전역 변수 등도 쓰이지 않는다면 webpack이 자동으로 트리쉐이킹 해준다. next 및 webpack version이 높아지면서 성능이 좋아졌다. 4. package.json 에서 sideEffects: false 옵션을 키면 코드들이 side Effect 가 없다고 가정하고, 휴리스틱하게 트리쉐이킹 해준다. 혹은 아래와 같이 특정..

회사에서 복잡한 react 컴포넌트(테이블)를 만들 일이 생겨서 c++의 namespace 기능처럼 provider 내부에서만 전역이고 밖에서는 사용 불가능한 context 기반의 라이브러리를 찾고 있었다. 그래서 찾은것중 하나가 jotai였고, 용량이 작고 꾸준히 업데이트 되는 점이 마음에 들어서 jotai를 사내 라이브러리 용으로 쓰다보니 다음과 같은 여러가지 의문이 생겨서 코드를 훑어보기로 했다. 바로, 1. context api는 상태가 하나 바뀌면 provider 하위 컴포넌트들이 전부 rerendering 되는데 jotai는 해당 문제를 해결하기 위해서 어떻게 구현했는지? 2. react에서 리렌더링이 되지 않고 현 상태값을 어떻게 알고 있는지?? 2번 의문이 뭔지 구체적으로 설명하기 위해서 ..

소프트웨어는 탄생과 동시에 생명 주기를 갖는다. 소프트웨어 개발자는 소프트웨어가 변경될 가능성에 더 신경써야 한다. 소프트웨어는 시간의 흐름에 따라 언젠가 죽음을 맞이하게 될텐데 초기 설계 단계에서부터 변경과 폐기에 유연한 소프트웨어를 개발해야한다. 특히 프론트엔드 개발은 개발 패러다임이 자주 바뀌거나 사용하던 라이브러리의 버전업 & 유지보수가 끝나는 일이 잦은 편이라 코드 폐기 & 수정에 유연한 프로그램을 만들어야한다. 그럼 프론트엔드에서 어떻게 유연한 구조를 가질 수 있을까? 개발자로 일하면서 기존 코드의 수정이 너무 힘들어서 좀 더 좋은 아키텍처를 만들수는 없을지, 어떻게 변경에 유연한 소프트웨어를 만들지 궁금해서 몇주간 찾아봤고, 해답을 모듈화와 추상화에서 찾았다. 모듈화 모듈화란 큰 시스템을 작..

주의: 이 글은 삽질기입니다... HOC(Higher-Order Component)란? 컴포넌트를 구현하면서 공통된 로직을 재사용해야할 때가 있다. 보통 공통 로직은 hook으로 처리하면 되지만, error boundary같은 wrapper component나 로깅을 구현해야할때가 있는데 js의 고차함수 개념을 활용한 HOC 개념을 사용하면 wrapper component를 쉽게 구현할 수 있다. (보통 HOC는 class component에서 많이 사용하는데 함수 컴포넌트에서도 사용 가능하다.) import { Component } from "react"; function withLogging(WrappedComponent) { return class extends Component { componen..

요즘 키보드만으로 브라우저를 조작할 수 있도록 공부를 해보고 있다. 이 글은 키보드 유저를 위한 tabtrap이라는 기술에 대해 다룬다. Tab Trap 모달은 사라질 때까지 사용자는 그 영역에서만 집중할 수 있어야하고, 모달을 닫기 전까지는 벗어나서는 안된다. 해당 기법을 위한 tab trap을 구현하는 방식은 간단한데 모달의 첫 엘레먼트와 마지막 엘레먼트를 체크한 이후, 마지막 엘레멘트에서 tab keyboard 이벤트가 들어올 경우 처음 엘레먼트로 이동시키고 반대로 첫번째 엘레먼트에서 shift + tab keyboard 이벤트가 들어올 경우 마지막 엘레멘트로 이동시킨다. dialog 코드 예시로 보자. // getPortal 함수, Portal 컴포넌트 등은 react의 createPortal를 ..

프론트엔드 코드의 특성 코드의 잦은 변경(디자인) 짧은 생명주기 정량적 평가(디자인, UI/UX)의 어려움 이는 테스트의 어려움으로 이어지게 된다. 프론트엔드의 특성을 잘 살린 잦은 변경에 대응 가능한 (react-testing library) 생명 주기에 구애받지 않는 (모듈화후 통째로 교체) 시각적 요소 평가가 편하게 (storybook & chromatic) 코드, 테스트 코드를 작성하는게 좋다. 프론트엔드 테스트의 종류 크게 두가지 요소로 나눌 수 있다. 기능적 테스트(소프트웨어 공학적 테스트) 시각적 테스트(디자인, UI/UX 등) 기능적 테스트 Static Test 정적 테스트는 코드를 실행시키지 않고 테스트를 하는 것 오타나 type에러 같은 개발자의 실수로 인해 발생하는 에러를 미연에 방지..

이전에 유저의 명령을 undo, redo 하기 위해서 유저가 실행한 커맨드 하나하나를 기록하여 스택에 쌓는 작업을 했었다. 그런데 다양한 인터렉션을 처리하려고 하다보니 여러 원자적인 연산(create, delete, update)들을 조합해 하나의 커맨드로 기록할 필요성이 생기게 되었다. 예를 들어 다음 예시 화면과 같이 부모 노드안에 자식 노드를 추가하려면 한번 추가할때마다 각각 두번의 연산이 필요하다. 1. update 연산 -> 부모 노드(시작 스탭)의 width, height가 커져야 한다. 2. add 연산 -> 자식 노드를 nodes 배열에 추가해야한다. (undo, redo할땐 두 연산을 하나로 합쳐서 작동해야한다.) 이것을 간단한 코드 예시로 보자면 다음과 같다. const [nodes, ..

일하면서 react-flow(https://github.com/wbkd/react-flow)를 써보던 중 해당 오픈소스 라이브러리에는 유저의 실행 명령을 기록해서 undo, redo하는 기능이 없다는것을 알게 되었다. 그래서 기획 상 필요한 undo, Redo 기능을 어떻게 넣을까 고심하게 되었는데... 배경지식 설명 해당 라이브러리는 node라는 배열과 Edge라는 배열을 가지고 const [nodes, setNodes] = useRecoilState(flowNodesState); // 배열 형태 const [edges, setEdges] = useRecoilState(flowEdgesState); const addChildNode = () => { setNodes((nodes: Node[]) => 새..

복잡한 비동기 로직을 사용할때 Suspense를 사용하면 데이터를 사용하는 컴포넌트와 로딩 & 에러 상태를 핸들링하는 방식을 분리시켜 선언적으로 프로그래밍이 가능하다. react-query나 recoil에서 suspense를 사용하는 방식을 지원해주는데 라이브러리의 지원이 없이 직접 처리하는 방식이 궁금해서 해보았다. 우선 suspense에 대해 인터넷에 찾아보니 나온 코드는 다음과 같다. function wrapPromise(promise: AxiosPromise) { let status = "pending"; let result = {}; const suspender = promise.then( (successResult) => { status = "success"; result = successRe..