イベントループと TypeScript の型から理解する非同期処理
この本は、ブルーベリー本の 8 章からインスパイアされて、 TS の型が示す情報から Promise というものを理解してみる、というアプローチで書いたJSの非同期処理の解説です。 これらの資料と合わせて読むことを推奨します。 JSのイベントループのイメージを掴む JSでは中々意識することが少ないですが、正しく理解するには OS レベルのスレッドの視点で考え始める必要があります。 ブラウザや Node.js では一つのスクリプト実行単位を1つのスレッドに割り当てます。それをメインスレッドと呼んだり、ブラウザだったら UI スレッドと呼んだりします。 例えばブラウザでは、これは秒間60回、つまり 16.6ms ごとにループを呼び出します。(node だったらこれがもっと短いです) 仮に setTimeout の実装がなかったとして、それ相当の擬似コードを書くのを試みます。 let handl
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho
mints: 5.7kb の TypeScript コンパイラを作った
世の中の TypeScript コンパイラが大きすぎるので作りました。 ここで試せます。 jsx と jsx pragma のサポートもしたので、 preact も動いています。 実装方針 ビルドサイズ第一 とにかく軽量に mints自体が他のコードをビルドするときの速度ではない点に注意 現状、まともなエラーレポートが出ない。エラーメッセージをインライン化するとビルドサイズが増えるため。 空白行と型情報を落とすだけ ES5 への変換や commonjs への変換は実装しない enum と constructor と jsx のみ transform する特殊対応をしている 真面目な構文解析をしてない 例えば 1+1*2 のような binary expression は結合順を解析してない。型を落とすだけなら不要 prettier でフォーマットされたコードはコンパイルできるのが目標(空白行
Node/Deno でソースコードにテストを書く
tl;dr ファイルをそれ単独で単体テストとして実行するボイラープレートを編み出した そのヘルパとして mizchi/test という実装を作った なぜソースコードにテストを書きたいか Rust や Python の doctest ではソースコードにテストを書く方法があります。 ソースコードにテストを書けると、コードとテストの心理的な距離が近くなってテストが書きやすくなる、という肌感があります。(諸説あります) 実装とテストが混ざって汚れるのが嫌という意見も理解できますが、それはありつつ認めた上で、あとでリファクタする前提で最初の一歩をその実装に書けると嬉しい、という気持ちがあります。 現状の Node だととりあえず assert するだけという単純なテストを書くことは可能ですが、構造化する方法がないので、簡単なスクラッチの時ぐらいしか行われません。 // test.js import
Svelte + TypeScript のベストプラクティスを考える
自分で Svelte + TypeScript を色々と書いてみたが、情報がまとまってなかったので、ここでまとめていく。 なぜ Svelte + TypeScript か Svelte + TypeScript はセマンティクスが単純で型が付く軽量な Vue として気に入っている。ビルドが軽量で他と混ぜやすいのが特に気に入っていて、React や Vue の他のシステムに対しても、末端のコンポーネントとして混ぜやすい。Vue は歴史的経緯でデータバインディングの仕様が混沌としているが、Svelte はESM First で構文解析時の処理に仕様を寄せてるので、とてもシンプル。 webcomponents として配布するモードがあるのも気に入っている。Vue React は単体のビルドサイズが大きすぎて webcomponents の末端にするのは難しい。 やりたいこと <script la
Git と GitHub の次を妄想する
GitHub みたいなサービスを今一から作るならどの言語・フレームワークを使うか GitHub の次は何かを考えてみるのは、現実に実現困難なのを忘れれば、なかなかに楽しいことではあります。ここではその妄想をやっていきましょう。 GitHub の抱える課題を分割すると、Git の問題と、 GitHub の提供する機能の問題に分けられると思います。自分は、Git をベースとして GitHub に勝つのは現代ではなかなか難しいと考えています。MS による買収と実際に注ぎ込まれてる資本を考えると、よほど斬新な切り口でないと、 同じ Git を使っても優位性は出せません。 なので、 GitHub に本質的に勝つには、その基幹となる VCS から考え直すとよいのではないか、と考えています。幸いなことに(?)、Git はその優秀さは認められていますが、学習の困難さや特定のユースケースで機能しないことが知
Next.js API Route の実装時に同じファイルでクライアントコードも実装すると嬉しい…
tl;dr API Route でクライアント用のコードも一緒に実装すると型安全に実装しやすい ただしセキュリティは気をつけてね 発想 Next.js から Prisma ORM を利用する という記事で、 Next.js の getServerSideProps で prisma のコードを使う例を紹介しました。 これは pages というユニバーサルなエンドポイントで、クライアントとサーバー用のコードを両方記述しています。 import type { GetServerSideProps } from "next"; import prisma from "../lib/prisma"; type Props = { count: number; }; export const getServerSideProps: GetServerSideProps<Props> = async
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Next.js から Prisma ORM を利用する