음악, 삶, 개발

최대한 Redux 의 사용을 피하고자 다른 대안이 있는지 뒤져보았다. Redux 코드들을 이것저것 보았는데, bolierplate 코드가 너무 심하게 많다는 느낌을 지울수없었고, 잘 와닿지도, 이해도 되지않았다. 이렇게 힘들게 상태관리가 되야하는가라는 느낌도 있었다. 이러한 이유로 뒤지다보니, 생각보다 npm 다운로드수가 높은 녀석들이 3개나 있었다. 1. zustand : 다운로드수 - 95,890 https://www.npmjs.com/package/zustand 2. recoil : 다운로드수 - 92,644 https://www.npmjs.com/package/recoil 3.jotai : 다운로드수 - 17,038 https://www.npmjs.com/package/jotai 자세한 내용은 더..

지난 1주일동안 React app 의 성능 향상을 위해 많은 자료를 찾아보고, 직접 실험도 이것저것 해보았다. 사실 음악 관련 GUI 를 리액트로 개발한 선례를 찾아보기가 힘들었기에, 스스로 파헤쳐내야 하는것도 꽤나 많았다. 일반 앱들과 음악앱이 다른점은, 음악앱에서는 UI 의 레이아웃 전환이 매우 빠르게, 매우 자주 발생한다는것이다. Ableton 을 생각해보면 수많은 UI 버튼, 슬라이더, 믹서 노브등이 떠 있는 상태에서, tab 키를 누르면 곧바로 다른 레이아웃으로 전환된다. 이 레이아웃 전환시 30ms 이상이 되면 사용자도 충분히 인지할수있으며, "어 조금 느린데? 왜 이러지?" 라면서 나에게 이메일을 보내게될수있다. 음악을 하는 사람들은 작은 타이밍의 차이도 매우 예민하게 잘 느낄수있기때문이다...

useEffect 를 통해 props 에 따라 다이나믹하게 div 의 레이아웃을 css 가 아닌 style 속성을 통해 변경해야할 상황이 생겼는데, 레이아웃이 변경될때마다, 화면이 깜빡거리는 일이 발생했다. 원인을 몇시간동안 추적해본 결과 useEffect 에서 style 을 변경하여 생기는 문제였다. useEffect 는 Max 에서 [delay] 객체를 사용하는것마냥 약간의 시간차를 두고 호출되는거같다. 이 약간의 시간차가 화면이 깜빡거리게끔 느끼게 하는것이다. 예를 들어, width 가 바로 0 이 되어야하는데, 40 에서 약간 떠있다가 0 으로 되어 깜빡이는것처럼 느껴졌던것이다. 결국 className 에 display: none 에 해당하는 class 를 asign 함으로써 문제를 해결할수있었다..

최근에 React 로 GUI 개발을 시작하면서 절실하게 느낀... 개발을 할수록 머리속에 예상된 가장 큰 점 하나는.. 미디나 오디오 관련된 코드보다 GUI 와 관련된 코드가 압도적으로 길것 이라는 생각이다. 왜 그러냐면, 우선 사용자 눈에 이뻐야하면서도, workflow 를 향상시켜줄 UX 여야만 하기때문이다. 결국 아무리 내부적으로 뛰어난 알고리즘을 장착하고있다하더라도, 사용성이 불편하다면 사용자의 외면을 받게된다. 이 둘을 동시에 떠올리는것은 생각보다 창의력 + 미적 감각을 요하는 굉장히 난이도 있는 작업이다. 미디 데이터나 오디오를 다루는 알고리즘을 잘 만들었다고 해도, 결국 GUI 를 하지않았다면 프로덕트로 향하는 길의 절반도 가지 못한것이다. 다시 말하지만 확실한건, GUI 관련 코드가 오디오..

React 프로젝트 생성 툴을 cra 에서 vite 로 변경하였다. https://vitejs.dev/guide/#scaffolding-your-first-vite-project npx create-react-app my-app --template typescript 에서.. npm init @vitejs/app my-vue-app -- --template react-ts 로 이동하였다. Vite 는 예전 vue 를 사용할때 써보긴했었는데, react 프로젝트를 생성할수있는줄은 몰랐다. 개인적으로 cra 보다 훨씬 빠릿한 느낌이 든다. 무엇보다 tailwindcss 를 사용하기위해서는 vite 랑은 이미 협업상태라 매우 잘 돌아가는데, cra 에서는 npm run start 를 계속 실행해줘야 css 가..

React 앱을 작성하다보면, className 이나 id 를 고유한 파일안에 const 로 정리해놓는것이 좋다. 추후 event listener 로 id 나 classname 또는 dataset 을 확인할때 유용하기때문이다. 나는 className 과 id 를 따로 구분하지않고 그냥 AppNames 라는 ts 파일안에 다 몰아서 적었다. 어짜피 id 면 suffix 를 숫자로 추후 붙여주거나 할수있기때문이다. /* AppNames.ts */ export const APP = 'app' export const APP_HEADER = `${APP}-header` as const export const APP_FOOTER = `${APP}-footer` as const 참조 : https://leestrum..

Node 에서 string 과 string 을 연결할때 ${} 기호를 자주 사용하곤한다. export const APP = 'app' export const APP_HEADER = `${APP}-header` // app-header 하지만 일반적으로 const 로 작성된 string 은 리터럴 type 으로 지정이 되는 반면, ${} 가 들어가버리면 string type 으로 지정이 된다. 대부분의 경우 상관이 없겠지만, APP 과 APP_HEADER 를 하나의 type 으로 사용하고자할때 문제가 된다. 우리가 기대하는건 'app' | 'app-header' 일텐데, 일괄적으로 string 으로 잡혀버린다. 이를 고치기위해서는 ${} 를 사용한 변수뒤에 as const 를 붙여야한다. export co..

위와 같이 깊게 들어가있는 폴더의 단축 경로를 tsconfig.json 에서 만들수있다. // tsconfig.json { "compilerOptions": { "baseUrl": "src", "paths": { "@foo" : ["nested/nested/nested/nested/nested/Foo"], } } 이때 반드시 baseUrl 을 설정해줘야하는것을 잊지말자. 저 baseUrl 을 기준으로 출발하기때문이다. 위와 같이 tsconfig.json 파일을 작성하였다면.. import { foo } from './nested/nested/nested/nested/nested/Foo' 에서 import { foo } from '@foo' 로 작성할수있게된다. '@' 는 꼭 붙이지않아도 되지만, 약간의 ..

Brad Frost on Twitter “Component developers, which way do you do it and why?” twitter.com This or that? Component Names: index.js or Component.js I'm not sure if you're aware, but there are sometimes different ways to do the same thing. Crazy, right? As a consultant I get to see a lot of different codebases, and I try study other projects' architecture in order to better understand this Brave Ne..

위와 같이 폴더 구조가 되어있는경우를 가정해보자. 나는 parent.ts 안에 내용물을 deelChild.ts 에 import 하려고한다. 그러면 아래와 같이 작성이 된다. 이런일이 일어나지않을거라 생각하겠지만, 거대한 app 을 작성하다보면 폴더 계층 구조가 점점 nested 되게 되고, 위와 같이 ../../../../ 의 지옥에 빠지게된다. 이렇게 되는 이유는 import from 의 경로가 현재 자신의 위치를 기반으로 출발하기때문이다. 이때 tsconfig.json 을 수정하면 본인이 원하는 경로에서 import 의 시작점을 지정할수있다. // tsconfig.json { "compilerOptions": { "baseUrl": "src" } } 위와 같이 tsconfig.json 파일안에, co..