11월 첫주차 기록

다시 따뜻해진 11월

배워가기

mobx에서 객체 상태 변경 감지하기

mobx의 autorun, reaction 등의 함수는 객체/배열을 인자로 받았을 때 변경사항을 추적하지 못하므로

객체/배열 상태 변경 시 동작을 trigger하고 싶다면 다음과 같이 배열을 새로 만들어야 한다

autorun(() => {
  console.log(store.chatList.slice());
  // 또는
  console.log(store.chatList.map((chat) => chat)));
});

Next.js Server Actions

"use server" 명령어로 서버에서만 동작할 함수를 정의할 수 있다고 한다.

export default function ServerComponent() {
  async function myAction() {
    "use server";
    // ...
  }
}

태초에 "use client"가 있었다…

Ref https://nextjs.org/docs/app/api-reference/functions/server-actions

webpack HtmlWebpackPlugin

webpack의 HtmlWebpackPlugin을 통해 진입점 index.html에 변수 또는 인자를 전달해줄 수 있다

// webpack.config.js
const constants = {
  GOOGLE_TAG_MANAGER_ID: "...",
  // ...
};

plugins: [
  new HtmlWebpackPlugin({
    templateParameters: {
      ...constants,
      env: PROFILE,
    },
    template: "src/index.html",
  }),
  // ...
];

<!-- index.html -->
<noscript>
  <iframe
    src="https://www.googletagmanager.com/ns.html?id=<%= GOOGLE_TAG_MANAGER_ID %>"
    height="0"
    width="0"
    style="display:none;visibility:hidden"
  ></iframe>
</noscript>

df 명령어

• df -H
  • df: 파일 시스템의 사용 가능 공간 확인
  • -H: 블럭 단위를 1024가 아닌 1000단위로 용량 계산하여 출력한다

animationed event

addEventListener("animationend", (event) => {});

onanimationend = (event) => {};

event.animationName으로 css에 정의한 animation keyframe 이름을 가져올 수 있다

Ref https://developer.mozilla.org/en-US/docs/Web/API/Element/animationend_event

이것저것

• mov 확장자 비디오 파일 - QuickTime. Apple이 개발했다. TV 하드웨어나 비디오 카메라에 흔하게 쓰이는 포맷이다. 애플 컴퓨터 환경에서 잘 작동하지만, 웹에서는 그렇진 않다.

기타공유

Next.js를 사용하는 이유 vs 사용하지 않는 이유

Kent C. Dodds의 Next.js를 사용하지 않는 이유

Dodds는 Next.js 대신 Remix를 쓴다. 그치만 Remix가 최고의 툴은 아니며, Next.js가 좋은 선택이 될 수도 있다는 점을 서론에 장황하게 서술해놨는데… 논란을 피하고자 하는 게 이 아저씨도 K-패치 되셨나.

• 대표적인 리액트 테스트 툴로 enzyme과 RTL이 있다면, Next.js는 enzyme에 가깝다. 직접 API를 노출하는 대신, 요청, 헤더, 쿠키 등을 개발자가 직접 다루게 한다. Next.js는 정적 빌드 타임 개선을 위해 web platform의 SWC 방식을 쓰는 대신, 직접 ISR이라는 방식을 개발했다. web platform의 방식에 따르는 대신 자체적인 방식을 고집하여 다른 프레임워크들과의 호환(?)이 좋지 않다는 점을 말하고 싶은 것 같다.

• Next.js는 Vercel로 배포하는데, 이것이 AWS 호스팅보다 생산적인지는 의문이다. 게다가 유연하지 못하다. Vercel에서만 배포 가능하다는 Next.js의 한계(?)를 없애주는 새로운 툴(OpenNext)이 나왔을 정도. 아무튼 독자적인 배포 방식으로 인해 Next.js는 유지보수가 어렵다. (심지어 Vercel의 요금은 나날이 비싸지고 있다.)

• Next.js는 React를 먹어치우고(?) 있다. 뭐가 Next.js고 뭐가 React인지 헷갈린다. (나도…) React의 장점을 취하고 도구를 개발한다는 점은 좋지만, React 팀과 제대로 협업하지 못하고 있다는 건 좋은 신호가 아니다.

• React 카나리 테스트로 배포한 것을 실제 유저들에게 제공하여 오히려 혼란만 가중시키고 있다. ‘잘 쓰던 거 왜 단종시켜!’ 느낌…

• 투머치하다. Next.js는 global fetch 함수를 override해서 자동 캐싱을 지원하기까지 하는데, 넘 과격하다. web platform을 어기면서까지 이렇게 하는 건 투머치다.

• Next.js는 점점 복잡해진다. 서버 액션이니 뭐니…

• 안정성이 의심된다. 벌써 v.13인데, 과연 stable하다고 주장할 수 있을까

• Next.js로 만들 수 있는 건 다른 것들로 만들 수 있다. Next.js의 불편한 점들을 감수하면서까지 가져갈 필요는 없다.

아무튼 Kent 아저씨는 Remix를 쓸 거라고 한다. 🤷‍♀️ 말 다 들어보니 그런 것 같기도 하고 ㅎ

이에 반격(?)하는 Lee Robinson씨의 다음 글도 있다.

Lee Robinson의 Next.js를 사용하는 이유

• Next.js를 배우는 것은 web platform을 배우는 것이다. Remix는 Next.js보다 한참 늦게 출시되었고, 그 사이에 많은 것이 바뀌었다. 2019년에 나온 Next.js의 API Routes는 Node.js를 기반으로 하며 Express와 유사하다. 또 2021년에 나온 Next.js 12부터는 Web API 기반의 middleware를 사용할 수 있다. Next.js도 web platform의 규칙을 따라가고 있다!

• 모든 Next.js의 기능들은 self-hosted로 운영된다. 이미 굴지의 기업들이 Next.js의 self-hosting 방식으로 웹서비스를 운영 중이다. 가격이 비싸다는 건… Vercel에서 개선 중이다. 

• 서버 컴포넌트와 서버 액션은 Vercel과 독립적이다.

• React canary 채널은 Next.js 같은 프레임워크가 채택하기에 충분히 안정적이다. Next.js는 React의 미래에 베팅했다. React를 만든 Meta 팀과 더 협업할 것이다.

• 서버 컴포넌트는 이미 운영에 배포되었다. 그리고 Next.js는 언제나 성능과 안전성을 우선으로 취급할 것이다. 유저들을 당황시킨 급진적인 변화들은, 피드백을 반영하여 개선해나갈 것이다.

둘이 친한 것 맞는지? 아무튼 이렇게까지 딥하게 생각해본 적은 없어서 내가 누구 편을 들어주게 될진 모르겠다. 각자 주장하는 근거들이 많아서 반반 섞일 수도? 🥗

Ref

• https://www.epicweb.dev/why-i-wont-use-nextjs
• https://leerob.io/blog/using-nextjs

W3C 표준위원회의 노고를 잊지 않기 - 웹 컴포넌트 편

요즘 다들 쓰는 React도 짱이지만, 그 역사 속엔 Web Component라는 것이 있었다… 그리고 여전히 짱이지!

Ref https://jakelazaroff.com/words/web-components-will-outlive-your-javascript-framework/

Node v21.1.0

21이라고..? 왜 그러는데…

21에서는 ESM 문법 자동 실행을 탑재했다고 한다.

Notable하네…

Ref https://nodejs.org/en/blog/release/v21.1.0

Eslint의 포매팅 관련 규칙들 제거

정적 분석 툴의 역할에 더 집중한다고 한다.

왠지 서운해. 그냥 하던 거 계속 해주면 안 되나.

그래도 아주 다 없애진 않나보다.

Ref https://eslint.org/blog/2023/10/deprecating-formatting-rules/

배럴(Barrel) 파일의 대실패

원문: https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-7/ 요약: 많은 프로젝트에 다른 파일을 다시 export하는 파일들로 가득 차 있습니다. 소위 “배럴(Barrel) 파일”이라고 불리는 이런 파일은 대규모 프로젝트에서 자바스크립트 툴이 느려지는 주요 원인 중 하나입니다.

속도 향상을 위해 배럴 파일 사용을 지양 해야 한다는 글이다.

배럴 파일: 폴더 entry로 import문을 모아두는 파일

자바스크립트 런타임은 전체 시간의 극히 일부에 불과하다. 도구에 소요되는 시간은 프로젝트 코드를 실행하기 전에 소비된다.

번들러가 주로 하는 일은 모듈 그래프를 평탄하게 만들고 병합하는 것이다. 코드 실행 시간에 문제가 있다면, 모듈 그래프의 크기가 문제일 수도 있다. 그리고 배럴 파일이 그 주요 원인이다.

배럴 파일은 다른 파일만 내보내고 코드 자체는 포함하지 않는 파일이다.

// feature/index.js
export * from "./foo";
export * from "./bar";
export * from "./baz";

import { foo, bar, baz } from "../feature";

이렇게 거미줄처럼 얽힌 import문은 모듈 로드 시간을 더 잡아먹을 뿐이다.

결론: 코드에 배럴 파일이 몇 개만 있는 것은 보통 괜찮지만, 모든 폴더에 배럴 파일이 있으면 문제가 된다. 모든 배럴 파일을 제거하라!

Ref 자바스크립트 에코시스템의 속도 향상 - 배럴(Barrel) 파일의 대실패

Vercel font

Geist? 어떻게 읽는 거야…

Ref https://vercel.com/font

vite가 rollup과 esbuild를 대체한다?

지난 vite conf에서 발표된 내용으로, vite가 rollup과 esbuild를 대체할 것이라고 한다.

rollup의 rust 포트로 rolldown이라는 프로젝트를 진행하며, 사용자에게 최소한의 영햠 범위로 esbuild와 rollup을 대체하는게 목표라고 한다.

원래 vite가 내부적으로 rollup도 esbuild도 다 쓰고 있지 않았나 🙃 너무 많아서 이제 뭐가 뭔지도 모르겠다.

Ref

• https://twitter.com/youyuxi/status/1709943106215530867?s=20
• https://docs.google.com/presentation/d/1oZnjsPBnb3OB2HxU88vYkZLa54GV-xNKrF8XkOIqLAU/edit#slide=id.p
• https://viteconf.org/23/schedule

감성적인 LLM

LLM에 감정적인 자극을 더해주면, 더 나은 품질의 이해와 답변을 제공하는 현상이 관찰된다는 보고.

• “이 코드 좀 짜봐” 👉 “퉤”

• “이 코드 좀 짜줄래..? 내가 진짜 오늘까지 마감해야 되는거라 그래… 부탁해…” 👉 “function process(): WithGreatAnswer { …”

Ref https://arxiv.org/abs/2307.11760

마무리

어느새 11월, 그리고 항상 추운 겨울의 시작 전에 갑자기 따뜻해져버리는 날씨

빠르게 연말 분위기에 취하고 싶지만 아직 맡은 일이 하나도 끝나지 않았기 때문에 경계를 늦출 수 없다! 😖