サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
タスク管理術
www.mizdra.net
React + CSS Modules なプロジェクトを例にサンプルコードを書いてるけど、それ以外の構成のプロジェクトでも使えるテクニックのはず。記事タイトルは id:hitode909 さんの 似ているけどちょっと違うものたちをモデリングする技術 - hitode909 のリスペクトです。 data 属性, 属性セレクター, CSS カスタムプロパティを使う 記事のリストがあって、記事のカテゴリごとに文字色やボーダーの色を変えたい、みたいな状況だったとする。多分素朴に書くと以下のようになるはず。 import styles from './Entry.module.css'; import clsx from 'clsx' function Entry(props) { return ( <div className={ clsx(props.category === '暮らし' ? s
TL;DR あるリソースの fetch 中にページ遷移すると、一部ブラウザでは fetch が中断される 中断されると、TypeError が throw される ページ遷移時は、ブラウザによって遷移前のページの実行が"停止"され、"捨てられる"ので、通常 throw された後のことは考えなくて良い しかし、そのページが Back/Forward Cache から復元されうるなら、話は別 ブラウザバックすると、エラーが throw された後からページが再開される!!! そして発生する、奇妙な現象の数々... はじまりは、あるサービスの不具合報告 ある日、「Webサービスから外部サービスにページ遷移した後、ブラウザバックで戻ると、エラー画面が表示される」という不具合が報告された。どうも Webサービスの ErrorBoundary で何かしらのエラーが catch され、それによってエラー画
これは、はてなエンジニアアドベントカレンダー2023 4日目の記事です。 3日目は id:mechairoi さんの「SQLiteでLinderaを使った日本語全文検索」でした。 blog.chairoi.me 今日のテーマは、JavaScript 向けの Linter 「ESLint」についてです。ESLint を使うと、JavaScript で書かれたコードを静的解析して、よくある間違いを検出したり、コーディングスタイルを統一できます。 通常、ESLint のルールによって報告された問題 (error や warn) は人が手で修正します。ただし、ルールが報告する問題の中には「fixable」な性質を持ったものがあります。こうした fixable な問題は、eslint --fix で自動修正できます。例えば、object-shorthand ルールによって報告された問題は、以下のよう
GraphQL を使って Web アプリケーションを実装していると、GraphQL API のリクエストをモックしたいことがあると思います。 ユニットテストのために、ダミーレスポンスに差し替えたい ビジュアルリグレッションテストのために、ダミーレスポンスに差し替えたい Storybook で story を書くために、ダミーレスポンスに差し替えたい バックエンドの resolver 実装を待たずにフロントエンド側の開発を始めるために、ダミーレスポンスに差し替えたい 一般には GraphQL Client にモックするための機能が実装されてるので、そうしたものを使うことが多いと思います。 zenn.dev また最近は Client よりも外側のレイヤーでリクエストを interrupt してモックする「msw」を使うケースも増えてきてます *1。 blog.engineer.adways.n
多言語対応している Web アプリで、あらかじめファイルに書き出しておいた画像 (アセット) が言語別にあって、それをページに埋め込むにはどうするか、という話題です。基本は言語ごとに別々の画像を出すことないと思いますが、たまーにあるんですよね。例えばGoogle Play のバッジが言語ごとに違うので、これを言語ごとに出し分けたいとか。 Google Play バッジ – Google 色々方法があるので、それをいくつか紹介します。 方法1. import 文を言語の数だけ書く シンプルにやるなら、言語の数だけ import 文を書いて、next/image の <Image> コンポーネントで読み込むコードを書くかと思います。 // pages/index.ts import Image from 'next/image'; import GooglePlayJaJP from '../
Web ページを作るときに、あらかじめファイルに書き出しておいた画像 (アセット) をページに埋め込みたいことがよくあると思います。例えばヘッダーにサービスのロゴ画像を埋め込む場合、以下のようなコードを書くと思います。 // src/components/Header.tsx export function Header() { return ( <header> <img src="/assets/logo.png" alt="Logo image" /> {/* ... */} </header> ); } 一方で、最近のWeb フロントエンドフレームワーク (例: Next.js, Remix) を使う場合は、import 文を用いて以下のように書くことが多いと思います。 // src/components/Header.tsx import I_LOGO from '../asse
npm package を作る度にイチから開発環境の構築をしていて大変だったので、自分専用のテンプレートリポジトリを作りました *1。 github.com せっかくなので、テンプレートの特徴とか、どういうこと考えながら作ったとか紹介してみます。 はじめに: 基本的な技術スタック npm TypeScript Node.js Native ESM Prettier ESLint Vitest Renovate GitHub Actions vscode 向けの各種設定ファイル (extensions.json, launch.json, settings.json) GitHub の「テンプレートリポジトリ」機能を使う GitHub にそれっぽい機能があったので使ってみました。 docs.github.com 「Use this template」というボタンが出て便利です。 「Use t
去年の 11 月から続く一連の騒動を受けて、id:mizdra のフォロワーの中でも Twitter から Fediverse に移行してきている人が増えてきた。僕自身は移行するつもりはないけれど、移行したフォロワーが僕のツイートを Fediverse から見れるように、ツイートを Mastodon へと転送するようにしてみた。せっかくなので、そのやり方について書き残しておく。 作戦 IFTTT という「〇〇したらXXする」みたいなピタゴラスイッチをボタンポチポチで作れるサービスがある。これを使い、当該 Twitter アカウントでツイートがされたら、それを契機に Mastodon にトゥートを投稿する、というピタゴラスイッチを組むことにする *1。 転送する上での注意点 (2023/4/10 追記) (トラバで情報を頂いたので追記) 今回紹介する方法では、普段は自動投稿のみをする BOT
Next.js で開発していると、複数のページの getServerSidePropsで同じようなコードを度々書くことになると思う。例えば 「GraphQL クライアントでクエリを fetch して、そのレスポンスをpagePropsに焼き込むロジック」であったり、「(マルチテナントアプリケーションにおいて) リクエストヘッダーからテナントを特定するロジック」であったり。こうした大部分のページで使われるロジックのコードは、何度も書かずに済むよう、何らかの共通化をしたくなる。 すでに色々な人が似たような動機でgetServerSidePropsを共通化する方法を紹介していると思う。それを参考にしながら id:mizdra も自分流の共通化方法を実践している。何度か Next.js アプリケーションを作っているうちに、自分の型のようなものが身についてきたので、それを紹介してみる。 はじめに結論
登壇とかではなく、いち聴者として参加してきました。 yapcjapan.org 前日祭も参加していて、土日での京都滞在でした。 yapcjapan.connpass.com 僕と YAPC YAPC への参加は去年の YAPC::Japan::Online 2022 に続いてとなり、YAPC::Kyoto 2023 で2回目です。オフラインの YAPC は初めてでした。 また、別の話として新卒入社のタイミングがコロナと重なっており、参加人数が数百人超える大きなカンファレンスに出たことがほとんどありませんでした (入社前のものを含めると HTML5 Conference 2018 と builderscon tokyo 2019 くらい?)。大きなカンファレンスへの参加が4年ぶりということで楽しみにしてました。 印象深かったセッション moznion さんの廃墟の話が印象深かったです。出てく
id:mizdra は eslint-interactive というツールをメンテナンスしています。このツールを使うと、多数の ESLint エラーを効率的に修正できます (詳しくは以前書いた記事を見てください)。 www.mizdra.net eslint-interactive では「中規模〜大規模なコードベースであってもキビキビ動く」を大事にしてます。その一環として、eslint-interactive には CI (GitHub Actions) でベンチマークを取り、以前から大きく劣化していたら CI を fail させる仕組みがあります。 https://github.com/mizdra/eslint-interactive/actions/workflows/benchmark.yml?query=is%3Afailure しかし CI で実行するためにノイズが大きく、よく
ある機能を実装する際、完成形のコードになるまでには、プログラムとして不正確な状態や、プロダクト品質ではない状態を経る 静的型検査や lint rule に違反したコードが途中に挟まる 型エラーや lint エラーは望ましくないので、できるだけ早くこうした情報を開発者に伝え、気付けるようにすると良い CI でこうしたエラーを検知して、Pull Request をマージする前に気づけるようにするとか エディタ上にエラーの情報を表示して、コーディング中に気づけるようにするとか エラーを積極的に通知してくれるのはありがたいけど、やりすぎには注意するべき なんとなくでも動いてくれたほうが嬉しい 例えば lint エラーがあった際に、watch モードで起動しているビルドやテストの実行を止めて、lint エラー見つけたよーと教えてくれる開発環境がたまにあるけど... 別にビルドやテストの実行は止める必
Web フロントエンドにて、Canvas を使った View のテストを書きたいことがたまにあります。ブラウザであれば以下のようにして Canvas を利用できますが、テストが実行される Node.js ではそのような API は生えていません。 const canvas = document.createElement('canvas'); canvas.width = 200; canvas.height = 200; const ctx = canvas.getContext('2d'); ctx.fillStyle = 'green'; ctx.fillRect(10, 10, 150, 100); そこで Node.js では、node-canvas という npm パッケージがよく使われます。これを使うと、Web Canvas API 互換な API を用いて、Node.js
テスト書く腕力鍛えるため & 個人開発のメンテナンスを楽にするために、最近なんでもテストコードを書きまくってます。あらゆるものをテストするぞという気概を持って手を動かした結果、ちょっと変わったテストコードを書いたりしてました。というわけで、この記事ではそれらを紹介していきます。 CLIツールの E2Eテスト dotfiles のインストール可能性のテスト ブラウザ拡張機能の content script の E2E テスト Scrapbox の UserScript の E2E テスト VSCode のコードジャンプの振る舞いのテスト レンダリングパフォーマンスのリグレッションテスト メモリリークのリグレッションテスト おわりに CLIツールの E2Eテスト 「eslint-interactive」という ESLint の error/warning を高速修正する CLI ツールがありま
個人開発をテーマにしたこちらのイベントで、5 分の LT をしてきました。 nota.connpass.com 今回は Scrapbox で議事録を高速に取るための UserScript「icon-suggestion」を作った話をしました。 youtu.be scrapbox.io 個人開発というと、限られた時間と人手で開発しなければならないため、ついつい動けば良い状態になってしまいがちです。テストコードがなかったり、リファクタリングされずにコードが継ぎ足しされた結果、インターフェイスがめちゃめちゃになっていたり... 個人開発では開発者が1人なので、自分がコードを理解できていればよく、コードの品質の優先度が相対的に低くなるので、ある意味当然と言えます。id:mizdra もよく動けば良いやと書き散らしてます。 icon-suggestion の開発はあえてその逆をいってて、拘ってテスト
Webフロントエンド界隈の文献などにあたっていると、「コロケーション (co-location)」という考え方が時々登場します。 コロケーションを簡単に説明すると、関連するリソース同士を近くに置いておく、という考え方です。 FooComponent.tsx と同じディレクトリに FooComponent.test.tsx を置く GraphQL fragment は、クエリを発行するコンポーネントファイル (pages/user.tsx) ではなく、fragment を利用するコンポーネントファイル (components/UserInfo.tsx) の中で定義する pages/user.tsx からはサブコンポーネントのファイルで定義されている fragment を import してきて、クエリを組み立てて発行する API ドキュメントは API.md に書くのではなく、コードの中にド
この記事は「はてなエンジニア Advent Calendar 2022」の3日目の記事です。2日目は id:pokutuna さんの「Slack チャンネルのロボット帝国化を防ぐ feed-pruning-proxy」でした。 blog.pokutuna.com さて、TypeScript で React コンポーネントを定義する時、皆さんはどういう書き方をしてますか? 関数宣言/アロー関数どちらを使って書くか、React.FC を使うかどうか、など微妙に人によって書き方が異なると思います。 その中でも、よく使われるのは以下の 3 つのスタイルでしょうか。 import React from "react"; type ButtonProps = { children: React.ReactNode; }; // 関数宣言。 function Button1({ children }:
DBMS に依存するロジックのテストを書く時、主に2つの手法があると思います。 Repository 層などを mock する Service 層のテストをする時は、その下位の Repository 層を mock して、DBMS に依存しない形にしてからテストする レイヤードなアプリケーションで適用できる手法 テスト実行時も DBMS を裏で動かして、それを使う 本番と同じスキーマを持つ DBMS に対して、実際に insert したり select してテストする DBMS は docker-compose upとかで事前に立ち上げておく 双方にそれぞれ良さがあって、プロダクトによってどっちでやるか変わってくると思います。 この記事では 2 の手法を Prisma でどうやるかについて紹介します。 前提 実際のテストコードの例 テストヘルパーを作る 別解: ヘルパーを自動生成する je
弊社では React で CSS を書くための手法として CSS Modules を全面的に採用しています。そこで CSS Modules を使った開発をより快適にするために、「happy-css-modules」というツールを作りました。 happy-css-modules のデモ。 この記事ではこのツールが必要になった背景、導入方法、そしてツールの技術的な仕組みについて紹介します。 CSS Modules の問題点と、typed-css-modules による解決 CSS Modules では、デフォルトでは存在しないクラス名を使用しても、(プロジェクトの設定次第ですが) TypeScript のコンパイルエラーが出ることはありません。 import styles from './Button.module.css'; function Button() { return ( <but
最近調べた qwik というライブラリが結構面白かったので、実際どういうものなのかとか紹介してみます。 qwik とは qwik は Web 向けの View ライブラリです (React や Vue.js の仲間)。パフォーマンスオタクがパフォーマンスの最適化 (Web Vitals の改善) にこだわって作ったライブラリです *1。 すでにいくつも良い紹介資料があるので、まずはこれらをいくつか読んでみると良いと思います。 Resumable な JavaScript フレームワーク Qwik を学ぶ Qwikの基本概念である Resumable を理解する Qwikというフレームワークについて - console.lealog(); Qwik調べてみたら結構面白かった qwik の詳しい使い方などは先人の記事に譲ることにして、以降は id:mizdra が個人的に面白いと思ったことを書
id:mizdra は時々仕事で「今の時点で結論を出す必要はない、遠い未来の話」をすることがあります。1年後に考えれば良いことを、今考える、とかです。それをするのは何故か、という話を今日はします。 長期プロジェクトを段階的に進めていくには、不安が付き物 現在 id:mizdra はレガシーな Web アプリケーションへの Next.js の導入を仕事でやっています。新規実装部分から少しずつ Next.js を導入していて、段階的に Next.js 化を進めています。全部一気に Next.js 化するとなると、「レガシーな技術スタックでやってたアレは Next.js/React でどうやるの?」という問いが絶え間なく発生して全く前に進めなくなります。しかしスコープを小さくすれば、少しずつ問いに答えていって、進行できます。途中で方針転換もしやすいし、最初の機能をリリースするまでの時間も短くなり
普段からいくつか趣味で作ったツールやライブラリを npm パッケージとして publish しています。ちょっと工夫していることとして、「できるだけ簡単に npm publish できるようにしておく」というものがあります。npm publish が心理的に、手順的に難しいと、すでに main ブランチに新機能や修正が入っているのに、npm publish されていない、という状況が発生しがちです。新機能や修正をすぐにユーザに送り届けられるよう、npm publish は無思考でできるようになっていると嬉しいです。 その一環として、リリースノート (CHANGELOG) の自動生成というのをやっているので、その紹介をしてみます。本当は 6 月にやっていた Maintainer Month 期間 に間に合わせたかったのですが、とろとろしていたら 7 月になってしまった! まあ遅れたから公開し
「React コンポーネントってどこまで細かく分割していいの?」とか、「Jest のスナップショットテストテストってどんなテストにも使っていいの?」とか、技術的な落とし所をどうするか悩むことは結構多いと思う。 コンポーネントを分割すると、責務が小さくなったり、再利用しやすくなったり、変更に強くなったり、各種ツールから利用しやすくなったりと、色々なメリットが得られる。けど、だからといってコンポーネント分割のしすぎは良くないと思う。コンポーネント分割するとなると、(そのプロジェクトの規約によるけど) コンポーネントファイルを新しく作らないといけないし、CSS Modules 用の *.module.css ファイルも作らないといけない。ファイルが増えることで、開発中に色んなファイルを行ったり来たりすることになって、作業効率が落ちる場合もある。コンポーネント分割だってタダじゃないし、デメリットも
「こういう取り組みをチームで始めてみたい」だとか、「新しいコーディング規約を考えてきたので、これを導入してみたい」だとか、「こういうツールを導入してみたい」だとか、チームに対して提案をする場面というのはよくあると思います。実際に提案する際には、以下のような 4 つのフェーズからなるフローで進めることが多いと思います。 提案の概要をまとめた資料 (提案書) を作成する 何故それをやりたいのか (背景・動機) どんなことをやりたいのか、やってみてどんなメリットがあるのか 懸念やデメリット、代替案などはあるか 1の提案書を誰かにレビューしてもらう 意見をもらって、提案書を適時修正するフェーズ 再度レビューに出して、チームから承諾をもらう 提案を実行する で、この 2 についてなのですが、id:mizdra はこのフェーズで傾聴を大事にしています。レビューに出したら、色々な人からフィードバックコメ
あるライブラリを使っていてバグっぽい挙動に遭遇した時、ほぼ必ず当該ライブラリの Issue を検索するようにしている。加えて、見つけた Issue の subscribe ボタンを押して、https://github.com/notifications に通知がいくようにしている。バグ遭遇時以外にも、何らかの理由で Issue に到達した時にその Issue を subscribe してる。 ハマったバグの Issue を見つけた時 欲しい機能の feature reuqest の Issue を見つけた時 例: Docker for Mac の VirtioFS 対応の Issue その他面白や動向をチェックしたい Issue を見つけた時 例: TS 4.7 のリリース計画について議論している Issue 例: Jest の ESM 対応の Meta Issue 例: ESLint の
かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil
趣味開発で使っている dotfiles をリニューアルした。 github.com 以前までの dotfiles では適切なパスへの設定ファイルの配置や、onetime script の実行タイミングの管理に ansible を使っていた。冪等性を確保するために色々な機能が用意されていて、便利ではあったのだけど、ファイルの配置をするだけで色々なおまじないが必要だったりと、若干冗長だなと感じていた。 シンボリックリンクを貼るタスク シンボリックリンク貼られる側のファイル郡 あと ansible 自体のインストールにそこそこ時間が掛かるという問題がある。GitHub Actions 上でインストールに掛かる時間を測ったところ、2分くらい掛かっていた。 GitHub Actions のログ (Install Ansible が ansible のインストールをしてい部分) dotfiles そん
「ページの編集は大胆に」という考え方 Wikipedia のページの執筆にあたってのガイドラインの1つに「ページの編集は大胆に」というものがあります。簡単に言えば、ちょっとした編集に留まらず、必要であれば大きな編集もしよう、という指針です。 最初のうちはちょっとした編集を積み重ねていくだけで上手くいっていたはずが、次第に文章がつぎはぎになり、やがて行き詰まる…。このような経験をしたことのある人は多いと思います。文章の元の体裁を尊重して少しずつ手を加えていくのも大事なことです。しかし、どんなに優れたページであっても、編集が積み重なっていくと、思うような体裁にならない時がやってきます。そうした時は大胆な変更をしていくべきだということです。 非常に素朴な指針ですが、文章を変更する上で大胆にやっていくというこの心がけはとても大事なことだと id:mizdra は思っています。当該ガイドラインのペー
ここ2年くらいの話なのですが、仕事で「フロントエンド会」というチーム内委員会のようなものを立ち上げて運営しています。元々1人の Web フロントエンド職人がプロダクトの Web フロントエンドの面倒を見ていたのですが、その方が異動されることになったので、残った人で面倒を見ていける体制を作りましょう、というモチベーションで発足した会でした。この話については以前イベントで発表したので、詳しくはこのスライドをご覧下さい。 speakerdeck.com Web フロントエンド職人の異動とともに入社した id:mizdra が Web フロントエンドが得意だったので、ペアプロやペアオペ、定例会などを通じてどんどんスキルや知見を配っていく、という戦略で運営していました。実際に 2 年経過してみてメンバーも徐々にキャッチアップしていって、ちょっとしたパフォーマンス改善をやってみたり、最近 Gulp や
次のページ
このページを最初にブックマークしてみませんか?
『mizdra's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く