React에서 가장 많이 쓰는 전역 상태관리 프레임워크를 삼대장을 꼽자면, 한국에서 가장 많이 쓰는 Redux, 한국에서 한참 뜨고 있는 Recoil, 그리고, 한국에서 최근 주목받기 시작한 Zustand가 있다. 이 중, Zustand는 가벼우면서도 강력한 확장성으로 요즘 주목받고 있는 프레임워크다. 오늘은 이 Zustand를 만든 모임, Poimandres 에서 만드는 리액트 상태관리 라이브러리를 알아보고자 한다. 이들이 만드는 리액트 상태관리는 기본적으로 아래 공통점을 가지고 있다. 기본적으로 리액트에서 작동해야 한다. 그러나 리액트 외에서도 동작할 수 있어야 한다. 그렇기 때문에, Astro 같이 여러 프론트엔드 기술 짬뽕으로 섞어먹는 아일랜드 식탁같은 프레임워크에서도 쓸 수 있다는 장점을 가지고 있다. 이 모임을 이끌고 있는 @dai-shi 라는 일본인이 있다. (본명은 링크에 있으니 봐라) 이사람이 누구냐

오늘 한번 리액트 개발자들을 내가 시험하려 들 것이다. 함수 컴포넌트 기준이다. 틀니 달고 클래스 컴포넌트 쓰고 싶지 않다. 장점 자바스크립트를 최대한 사용 너희들, jsx 쓰면서 마크업에다가 Array.prototype.map 같은 거 많이 쓰는 거 안다. 그게 왜인지는 알고서 하는 거라 믿고 있겠다. 어쨌든, 리액트는 스크립트의 기능을 최대한 활용할 수 있다. 그렇기 때문에, 개발자는 코드에 집중이 가능하기 때문에 구조화가 용이하다 하겠다. Vue와 Svelte 와는 견줄만 한 장점이라 하겠다. (Solid.js 무시하지 마라) 타입스크립트와 궁합도가 최강인 기술 내 개인적인 견해로 봤을 때, 주요 프론트엔드 기술에서 타입스크립트 궁합은 현재 끝판왕이라도 해도 손색이 없다고 하겠다. 오죽했으면 타입스크립트 자체적으로도 JSX 프로세싱을 고려한 설계를 했을까 싶을 정도로 말이지. 유연한 컴포넌트 정의 뷰와 스벨트는 1파일당 하나의 컴포넌

자중하는 시간을 가지고 공식 문서에 기반한 팩트 위주로 글을 쓰도록 하겠다. Astro는 좁게 말하면 멀티 페이지형 SSG(Stataic Site Generator) 프레임워크다. 그리고 넓게 말하면, 그들이 주장하는 아일랜드 아키텍쳐형 사이트 생성기다. 물론 SSR 기능도 지원하지만, 기본적으로 멀티 페이지 SSG라는 것만 알아두자. 억지로 이 프레임워크로 SPA 앱 만들다 잡치지 말고. Astro 에 대해 들어보거나 체험해 보았다면, react, vue, svelte 등 주요 프레임워크의 통합 기능은 매우 강력한 것으로 알려져 있다. 혹은 나처럼 경험해 보기도 했을 것이다. 기본적으로, 이 react, vue, svelte 는 자체에서 제공하는 hydration, 즉, 페이지 결과물을 받아들이는 방식을 사용한다. 따라서, 이론적으로는 이 하이드레이션을 지원하는 프론트엔드 기술이라면 모두 다 지원한다고 보면 되는데, 아직까지는 리액트, 뷰, 스벨트, 솔리드, 프리액트 등의

오늘 제목 한번 어그로 끌어봤다. 너희들이 리액트 쓰든 뷰를 쓰든 스벨트 쓰든 난 관심없다. 하지만 가끔 프론트엔드를 보면 리액트만 프론트엔드고 다른 프론드엔드는 없다 말한다. 리액트는 산업에서 많이 쓰고 있으며 나머지는 제이쿼리 뿐이라는 글도 있다. 설마 보이는 게 그게 다가 아닌지 생각해보도록 하자. 오늘은 이런 아집과 편견을 깨보는 시간을 가져보도록 하겠다. 외주는 리액트만 있고 나머진 없다? 내가 전에 글을 올렸었다. 한국 IT 시장의 대부분이 여전히 SI를 위시한 외주시장이고, 이 위시한 대기업들이 죄다 Vue를 쓴다고. 특히, 네이버와 삼성 등의 대기업들이 Vue를 밀고 있다. 물론 LG처럼 리액트도 슬금슬금 기어나와서 시장을 다시금 리액트로 물들려고 하지만 한~참 멀은 수준이다. 그러면 SI를 나가면? 그렇다. 니들이 말하는대로 십중팔구 리액트라 보면 된다. 근데, 대한민국 IT의 프론트엔드 시장은 리액트 아니면 제이쿼리 둘 중 하나라는 흑백논리를 들고

React react-use React 18 호환성 개선 이후 저자 잠수 중으로 비추. 아래 프로젝트 사용할 것. React 17 이하 사용자들에게는 추천. @react-hookz/web React 18 이후 사용자들에게는 위 프로젝트보다 본 프로젝트 사용을 추천 위 훅보다 개수는 아직 적기는 하지만 활발히 활동중이며 SSR 작동 보장. Vue vueuse 현재 Vue 유틸리티 라이브러리 중 끝판왕. Composition API 위주로 지원하기 때문에 Option API를 고집하는 건 신규 프로젝트로 할 거면 개인적으로 아집이라 생각하고 Vue 3 Composition API로 갈아타면 정말 혜택이 많다. 타라. 제발 좀. 네이버도

작년에 Next.js 로 프로젝트를 만들면서, 특정 연구과제 프로젝트는 헤까닥 돌아가 미친 상태로 SvelteKit 로 구축한 경험이 있다. 실무다. 충격과 공포다 그지 깽깽이들아. 내 경험에 입각한 의견이니, 크로스체크는 본인에 맡긴다. 장점 빠른 개발: 확실히 컴포넌트 하나 만드는데 Vue보다 빨랐다. 컴포넌트 안에 구조 잡는 규칙이 빠지고 구문 중심으로 개발하기 때문이다. 물론 Vue 3.2 의 가불기 `` 쓰면 비슷해진다. 비동기 구문: React, Vue 에도 없는 {@await} 공식 구문이 `` 컴포넌트 안 부럽다. 쉬운 확장: 특히 아무 CSS 프레임워크 갖다 붙여도 일단 동작 잘 한다. PostCSS, SCSS 궁합은 최고라 자부한다. Plain JS와의 친밀도: 내가 Svelte 쓰면서 가장 좋은 경험을 했던 게, 바닐라 JS로 만든, 특히 DOM 건드리는 위주의 비주

Next.js 같은 SSR 지원 가능한 프레임워크를 쓰면서 가장 고생하는 게 바로 스타일링일 것이다. 물론 쌩으로 쓰는 건 지장 없는데 Styled components, emotion 등 스타일링을 리액트답게 체계적으로 관리할 수 있는 라이브러리를 사용할 경우 말이다. 사실 SSR 원리를 아는 리액트 개발자라면 볼 필요도 없는 뻔한 글이지만, 모르는 풋 사과 들에게 오늘 간단명료하게 설명하도록 하겠다. 풋 사과 이 글을 보는 너희들의 심정.jpg 리액트 SSR 특 리액트 SSR에 대해서는 별도로 검색해서 원리를 파악하도록. 여기서는 스타일링 라이브러리에 영향이 갈 수밖에 없는 특징만 설명하도록 하겠다. 사실 SSR, 즉, 하이드레이션(Hydration)을 간단하게 말하면, 리액트 엔진이 초기에 렌더링할 HTML 결과물을 서버 상

오늘은 프론트엔드 초보들이 주로 실수하는 패턴을 통해 왜 비동기에서 이렇게 하면 안되는지 설명하는 시간을 갖도록 하겠다. 길게 설명하기 귀찮으니 자세히 알고싶으면 용어를 검색해서 찾아서 배우도록. 흔한 예시 가장 많이 하는 실수로, 비동기로 대량 반복문 처리 시 비동기에 맡기는 게 아닌, 그냥 이런 식으로 단순한 반복문을 짜기도 한다. 자, 예시에서는 대량의 CSV 파일을 단순히 테이블에다 넣는데, 만약 CSV 라인 수가 십만줄을 넘는다 치자. 과연 이게 부드럽게 작동할까? 결론부터 말하겠다. 브라우저 뻗는다. 즉, 아무리 비동기라 해도 지금 반복해서 CSV 나누는 것부터가 이미 비동기는 아니게 되어 멈칫하는 브라우저를 볼 수 있다. 초보들은 Promise 나 그 떨거지들 안에다가 for loop을 많이 걸어도 비동기가 돌아갈 것이라는 실수를 저지르는데, 절대 그러지 말도록 하자. 이는 MicroTask 를 공부했다면 충분히 이해갈 설명인데, Mic

Astro 2.0이 출시되었지만 한국에서는 뭐 언제나 그랬듯이 뻔하게 관심이 그다지... 없는 참 삭막한 프론트엔드 분위기라고 하고 싶지만 그러면 니네들 기분 상할 테니 이미 말해버렸지만 할수없지 에라 모르겠다. 윗글 뭐냐고? 미리보기용 글이다. 벨로그는 요약으로 낚시할 수 있어서 좋네. 일단 내가 내 홈페이지(http://comne.kr)를 Astro로 만들었다. 그리고 쌩 react나 vue로 만든 페이지와 내 홈페이지를 비교해 보았다. 쌩 react나 vue로 소스보기 하면 뭔 껍다구만 나오냐 하지만, Astro로 만든 홈페이지는 컨텐츠를 볼 수 있다. 그렇다고 react나 vue 개발자들, 굳이 멀리갈 필요도 없다. SSG를 지원하는 react 및 vue 기반 프레임워크를 써도 같은 효과를 누릴 수 있다. 그래. 이제 본론으로 가야지. 아일랜드 아키텍쳐에 대해 들은 사람만

보통 우린 뭔가 자바스크립트 실행 상황을 알고싶을때, console.log 메소드를 실행하고 있다. 어자피 브라우저에서 어떤 객체를 넣든 객체 상황에 맞게 예쁘게 출력해주기 때문에 별 탈은 없다. 하지만 콘솔에 찍는 아주 유용한 메소드들이 존재하지만, 이를 모르는 이가 많다. 지금 내가 하고 있는 이 프로젝트에서도 그런 모습을 엿볼 수 있었는데, console.log 함수를 빈 함수로 치환하여 사용을 막은 코드가 있는데... 그것만 막았더라... 에휴... 할많하않. 어쨌든, 오늘은 MDN에서 일일이 찾는것보다 더 편하게 내가 알려주도록 하겠다. 프론트엔드 개발자들, 이거 필독 알제? consolelevel 왠만한 언어에 로깅 개념이나 프로젝트를 써봤다면 알 것이다. JS에서 제공하는 로그 레벨은 아래와 같다. `debug

혹시 리액트의 `` 컴포넌트로 알고 들어왔는가? 훠이~ 훠이~ 오늘은 Vue 에서 새로 생길 내장 컴포넌트 `` 에 대해 알아보도록 한다. 아직 Vue의 이 컴포넌트는 실험 단계이며, 변경 가능성이 있지만, 리액트의 `` 컴포넌트와 비슷하다. 따라했다고 해도 무방하다. 이거 말고도 Vue가 리액트 따라한 거 있고 반대로 리액트가 뷰 따라한 것도 있으니 서로 기분나쁘다고 아래와 같은 포스터 찍는 일은 없기 바란다. 워크래프트 1 포스터 컴포넌트 본문 변경점 setup() 함수는 async 못 붙인다. 지원을 안했기 때문이다. 하지만 `` 컴포넌트와 함께 사용한다면, 지원할 수 있게 된다. 그런 다음, 갖다 붙이면 된다. 간단하다. 감격스럽다. 하지만 안타깝게도 리액트의

실무에 SvelteKit 조지면서 꼼수부리는 팁을 공유한다. 닥치고 내말 듣고 따라해봐라. 반응형 Promise {#await} 블록은 Promise 를 갖다 쓸 수 있는 블록으로, 리액트나 뷰에서 보기 힘든 공식적인 비동기 처리 블록이라고 보면 된다. 초기화를 할 때 이렇게 하기 십상인데, 이렇게 하면 {#await} 블록은 쌩 까고 바로 {:then} 블록 내용이 뜰 것이다. 이유는 간단한데, 초기화 시 당연히 undefined 기 때문에 스벨트 컴파일러는 이를 Promise.resolve(undefined) 로 인지하고 처리한다. 만약, 초기 상태, 즉, 로딩 이미지 등을 뿌리든가 이런 내용을 표현하고 싶다면, 그냥 기약 없는 약속을 초기화 시켜주면 된다. 그러면 진짜 약속으로 바꾸기 전까지는 세월아~ 네월아~ {#await} 블록에 정의한 화면, 예를 들면 로딩 화면이 영원히 렌더링 될 것이다. 반응형 대상 변수 필터링

현재 내가 실무에서는 React를 하고 있지만 너희들이 내 근황 굳이 관심 가지고 싶냐? Vue 개발자에게 한마디로 어그로 끌어보겠다. 난 Vuex가 매우 싫다. 하는김에 React 개발자에게도 어그로 끌겠다. 난 Redux 도 매우 싫다. Vuex가 Deprecated 된 거 축하한다. 빠밤. Vue 3.2가 출시한지 꽤 지났다. 사실 나는 3.2가 나올 때 쯤에도 난 백엔드에만 몰두하고 있었다. 왜냐면 실무에 내 역할은 백엔드 뿐이었거든. 지금은 프론트엔드로 React 하고 있다. 그래서 Vue 근황에 대해서는 딱히 들은 것도 없다. 내가 안 찾아봐서. 그리하여 직접 찾아보고, 너희들에게 일용할 양식이 되어 무료급식소처럼 나눠줄 테니 감사히 먹도록. `` 내가 가장 기대하던 기능이다. 정식 기능으로 추가된 소식은 이미 알고 있던 터라 대충 커버 이미지같은 흐뭇한 미소가 절로 나올 정도다. 컴포넌트의 정의부터 노출까지 함수로 단 한번에 해결할

내가 Vue 와 Svelte 의 유용한 라이브러리를 소개했고, 얼마 뒤 보니까 많이들 쓰고 있더라. Vue 프로젝트의 단짝, VueUse Svelte의 안내데스크, svelte-add 자, 이번엔 리액트다. 좀 늦은 감이 있었지만. react-use 전에 react-use 를 잠깐 소개했었는데, React 18 나온 뒤로 계속 지켜보았으나 이녀석 개발자가 더 이상 응답이 없어 사실상 활동 중단이 된 상황. 그래서 React 18 미지원으로 이 라이브러리 사용자들은 답답할 수밖에. ...라고 한숨쉬다가 다시 들어가봤는데, 어? 2022년 5월에 React 18 지원하네? 어?? 끝이네...

어쩌면 리액트를 싱글벙글 쓰고있다가 내 글을 보면 어째 기분나쁠 수도 있을 것이다. > 아니, 외국에서는 왠만한 기업들이 리액트를 쓰는데? > 아니, 한국에서도 유명한 IT 기업들도 리액트를 쓰는데? 나도 안다. 나도 Next.js 실무 투입 했었고 심지어 SvelteKit 가지고 실무투입 중이다. 근데, 내가 알려주고 싶은 건, 현실이다. 기술도, 스택도, 뭐도 없다. 현실과 시장 상황 뿐이다. 너희들도 SI 악명은 익히 알고 있는 거 아니냐. 나는 이 지랄같은 바닥을 벌써 10년 넘게 밟고 있다. 자, 본문으로 돌아가서, 일단 SI 시장은 너희들이 생각하는 것과 달리 대한민국 IT 시장의 대부분을 차지하고 있다. 구글 검색으로 보면 한국 기준으로 리액트와 뷰가 후반양반으로 줄다리기 경쟁 중이지만, 시장 점유율을 보면, 중국처럼 뷰를 강제로 써야 하는 수준은 아니지만, 뷰가 우세하다고 할 수밖에 없다. 일본도 마찬가지로 뷰가 우세다. 이유는 혹시 일본에 개발중인 개발자 있다면

음... 일단 리액트봐 뷰와 달리 스벨트는 스타일 태그의 범위를 해당 컴포넌트 내로 엄격하게 제한하고 있다. 이유는 이슈 코멘트에 적혀 있는데, 번역은 시간나면 여기에 내용 추가해서 기재하도록 하겠다. 일단, 리액트나 뷰와 달리 스벨트는 유연한 스타일링을 지원하지 않는다. 따라서 현재 지원하는 범위 내의 방법을 써야 한다. 자식 컴포넌트 내 스타일링 사용 일단 자식 컴포넌트에 class 속성을 부여하면, 스타일은 부모 스타일이 아닌, 컴포넌트 스타일을 따르게 된다. 예를 들면, 이렇게 작성할 경우, 아래와 같이 생성된다. 즉, 부모 컴포넌트의 해시 따로, 자식 컴포넌트의 해시 따로 생성되어, 자식 컴포넌트의 스타일은 자식 내에서만 유효하다는 점. [REPL 보기](https://svelte.dev/repl/88c699452f7644afa71f101a

2016년 5월 25일 from blog.hazard.kr 이 글은 Github 소속 Electron의 메인 개발자인 Cheng Zhao(@zcbenz)의 기고글을 번역한 글이다. 원문: From node-webkit to Electron 1.0 시간에 쫓기고 작성하다 보니 오역이 있을 수 있다. 오역 교정 환영한다. > 아니 프리랜서가 시간관리도 못하고 왜 시간에 쫓겨다녀? > > 한국 프리랜서는 용병이 아니라 그냥 사업자를 빙자한 근로자거든요 ㅋ 이 글을 통해 내가 node-webkit를 재구성하다가 Electron 프로젝트를 시작하게 된 내역을 기고한다. 내역을 좋아하는 애들을 위해 커밋 내역과

자, CSR과 SSR 이 있다. 이 둘의 차이점은 기본적으로 알고 있을 거라 믿고 시작하겠다. 몰라? 화면 표현을 클라이언트에게 모두 전가하느냐, 아니면 서버가 어느정도 개입하느냐 그 차이잖아. 둘의 장단점이 있다면, CSR 장점 정적 파일만 제공하는 웹 서버 게시가 가능해져 더 다양한 게시 제공자(특히 Github Pages)에 서비스가 가능하다. 클라이언트와 서버의 경계가 명확해 확실한 업무분리가 가능하다. CSR 단점 트래픽 유발이 많아진다 (그래서 캐시관리가 중요하지) 클라이언트 환경에 따라 차이가 크다 (흔히 말하는 누군 되고 안되고) SSR 장점 서버의 트래픽을 절약할 수 있다. (필요한 정보만 뿌리면 되니까) SEO에 유리하다 SSR 단점 클라이언트와 서버의 경계가 모호하다 (거의 풀스택이 요구된다) 정적 파일만 게시 가능한 제공자에 서비스가 불가능하다. CSR에 유리한 분야 관리 패