コンポーネントベースで開発する時の CSS の書き方とコンポーネントの分類 (自己流)
React や Svelte でコンポーネントベースで開発するとき特有の CSS ノウハウってあんまり効かない気がする Twitter に書いたら反響があったので、自己流だけどまとめておく React Component の管理単位と、CSS としてのレイアウトの管理ポリシーは違うよね、みたいな話をマークアップエンジニアに時折されるが、そんな話は無視して完全一致させる。そういう星のもとで開発している コンポーネントの分類 ロジックコンポーネント レイアウトコンポーネント ブロックコンポーネント インラインコンポーネント 定義 ロジックコンポーネント Provider や hooks などのデータ処理だけを扱い、子に渡すコンポーネント 一切の CSS や DOM 実体を持たない レイアウトコンポーネント レイアウトコンポーネントは複数の子ブロックコンポーネント(または slot)を持ち、子ブ
フロントエンドとSPA職人の目指したものの歴史と概略
年末年始にフロントエンド論みたいな記事をいくつか見たが、僕ら古のSPA職人がやってきたフロントエンドという職域と目指していたものが失伝しかけている気がするので、ここに時代ごとに何を考えていたか、雑に書き殴る。 注意点として、 2004から始まるが、自分がプログラミングを始めたのが2010, 業務としてコードを書き始めたのが 2012 なので、解像度が高いのはそれ以降になる。 tl;dr 2004: 動き出す HTML 2011: 構造化のはじまり 2015: 贅沢品としてのSPAとコミュニティ分化 2017: 貧者のSPA 2019: 守破離としてのパフォーマンス 2004: 動きだす HTML AJAX の時代。要は XMLHTTPRequest で取得したコンテンツに応じて、動的書き換えをDOM書き換えを行うこと。今では名付けるほどでもない操作だが、HTMLが静的なものをやめたことは、
Cloudflare D1 がヤバい
まだ検証足りないけど、マジで想像通りのブツなら魂震えるかもしれん…。 Announcing D1: our first SQL database Cloudflare D1 = Edge SQLite Cloudflare D1 は Cloudflare Worker で、つまり CDN Network 上で sqlite が動きます。これだけなら普通の sqlite ホスティングなんですが、もちろん Cloudflare が出すからにはそれだけではなく、CDN Edge 上に Read Replica がバラ撒かれた sqlite になります。ヤバくないですか？ 僕はヤバいと思いました。 このヤバさを知るために、Cloudflare が開発した基盤についていくつか抑えておく必要があります。 Durable Objects は CDN 上の Actor モデルを構築できます。この Acto
プロを目指す人のためのTypeScript 本の感想 #ブルーベリー本
自分も教える事が多いので、読み手にどういう風に学んでほしいか、自分がどういう風に伝えるべきか、という視点で読んだ。 1章・イントロダクション そもそもTypeScript とはなにかみたいな話。 コンパイルエラーが出ている状態ではプログラムが完成したとは言えません。 力強い コンパイルエラーをただ避けるのではなく、利用する気持ち で TypeScript プログラミングに臨みましょう。 初心者に型違反の向き合い方を諭す話。IDEの補助になるとか。 TS年表で取り上げてるのが特徴的。exactOptionalProperty を取り上げてたり。 TSの型はランタイムに影響しない、という話を何度も解説している。これは初心者の誤解がとても多いので、必要だと思う。何度いっても、伝わって欲しい人に伝わらないのだが… enum や namespace については意図的に解説しない。過去のTS独自路線だ
(自分の) JavaScript のユニットテストの書き方
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
内部モジュールでは TypeScript をコンパイルせずに配る
主張 現代では、 npm に publish するものを除けば TypeScript をコンパイルして配布する必要はほぼないと考えています。 TypeScript のコンパイルをしない環境、例えば deno や rome を使うと、コンパイルをするというステップが省くことで開発体験が大きく向上する、という肌感があり、ローカル環境ならこのメリットを優先するべきと考えています。 基本的に、ビルドはフロントエンド/サーバーともに配布前の最後の一回だけでいいはず、というのが自分の主張です。 Rome Toolchain Deno - A secure runtime for JavaScript and TypeScript 理由 現代の npm のお作法に従うと TypeScript に依存したものを npm の registry に置くことは、あまりよくないこととされていますが、モノレポ内や特
Swdev: 真の No bundle frontend
みなさん、ブラウザ内で TypeScript が直接動いてくれたらいいなぁ、と思ったことはありませんか？ しました。 これができます。 どのようにうごいてるか Service Worker は合法 MITM とも言えて、 fetch 時のリクエストを好きに書き換えることができます。 開発時 初回インストール時に Service Worker をインストール コンパイラを内蔵した Service Worker がリクエストの拡張子に応じて js に書き換える Content-Type: text/javascript として SW でキャッシュして返却 TypeScript(.ts, .tsx) と Svelte(.svelte + preprocess) に対応 WebSocket サーバーを起動。ファイル変更を監視して、変更されたファイル名をブラウザに通知 変更されたファイルを Serv
2021年 は Fullstack Next.js 元年なので、有望な Next.js 系フレームワークを全部試した
この記事は、Next.js Advent Calendar 2020 の6日目。 突然だが、2021年 は Fullstack Next.js 元年になる。 その理由として自分は以下のものがあると思っている。 ベストプラクティスとしての TypeScript のデファクト化 Next.js の Dynamic Routes による動的パス、 getStaticProps/getServerSideProps による使い勝手の向上 Vercel によるISRの発明 prisma の成熟 Vercel / Serverless / Cloudflare Workers / Cloudrun 等による Node.js サーバーの運用コスト減 参考: Frontend Study #1: 基調講演 - Frontend 領域を再定義する Blog - Next.js 9.3 | Next.js R
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
