ブログ

昨今、特にフロントエンドのアプリケーションにおいて、技術的な役割よりもフィーチャー（feature）を起点としてディレクトリを構成する（package by feature）というする考えが一般化しつつある。たとえば、技術的な役割を起点としたディレクトリ構成（package by layer）は次のようなものだ。

このサイトの名前を「Yuhei Yasuda」から「yuheiy」に変更した。「Yuhei Yasuda」だと人名そのままだからサイト名っぽくなくて微妙だったけど、「yuheiy」ならそれっぽいかなと思ったので。

Astroにおいて、コンポーネントから画像などのアセットを読み込む場合、import文を使うことが一般的だ。

CSSのtext-wrapプロパティを使うと、テキストの行の折り返し方法を変更できる。text-wrap: balanceを適用すると、適用しない場合と比べて次のように変化する。

Storybookにおいて、Reactコンポーネントを使ったstoryを作成する際、単なるボタンのようなシンプルなコンポーネントであればcomponentプロパティに指定するだけで良い。

CSSのdisplay: noneやvisibility: hiddenによって不可視状態になっている要素を、表示して即座にフォーカスしたいということがある。たとえば、初期状態では非表示になっている検索ボックスを、ユーザーのインタラクションに応じて表示するような場合。そうしたとき、通常では、スタイルを切り替えてすぐにfocusメソッドを呼び出すだけで良い。

Tailwind CSSにおいて、スタイルの組み合わせを抽象化したいと考えたとき、対処としてはいくつかの方法が考えられる。

以前、「Tailwind CSSで引数のあるMixinのような仕組みを作る方法」というブログを書いた。しかしその後、調査を重ねていくうちに、以前書いたのとは別のアプローチの方が望ましいと考えるようになったため、改めて書き直すことにした。

JavaScriptにおいて、ある配列をもとにして別のオブジェクトを作成する場合、Array#reduceを使用することが多い。

先日、頼まれて知人のサイトを作った。載せられるコンテンツはほとんどないものの、会社っぽい体裁にはしたいとのことだ。そんなわけで、要素はほとんどないなりに、多少なりとも見栄えがするようにデザインしてみた。要するに、このサイトみたいな極端な作りにはしなかったってこと。

任意の要素に対して、ブラウザデフォルトのフォーカスリングが描画されるように明示的に設定したいことがある。たとえば、スタイリングの都合により一度取り除いたフォーカスリングを、ふたたび適用したいとき。

VS Codeの拡張機能であるTailwind CSS IntelliSenseを使用する際には、通常、CSSファイルに記述されたクラスは補完されない。というのも、Tailwind CSS IntelliSenseでは、Tailwind CSSの設定ファイル（tailwind.config.js）を基にしてCSSを算出しており、設定ファイルを介さずに実装されたCSSは無視されるからだ。

ReactのuseStateを使用する際、stateのスコープが必要以上に大きくなってしまうことがある。たとえば次の例のように、コンポーネントの中のごく限られた部分でしか使わないstateが、コンポーネントのどこからでも参照できてしまう。

ReactのUIコンポーネントライブラリを使っていると、あるコンポーネントによってレンダリングされるHTML要素の種類を変更したくなる場面がある。たとえば、通常はbutton要素としてレンダリングされるButtonコンポーネントを使うときに、代わりにa要素を使ってレンダリングしたいというケース。

根を詰めて取り組んでいた原稿がやっと手離れして、肩の荷が下りた。僕がこれまで経験して来た中で、最も重い執筆だった。

後日追記: 寄稿した特集がgihyo.jpにて全章無料公開されました。

僕は右利きだが、スマホはいつも左手で使う。だから、スマホに入ったPASMOを改札機にタッチするときは毎回フラストレーションを覚える。

以前、「本文エリア内の要素をpaddingのないコンテナとして実装する」という記事を書いた。本文エリア内の要素をすべて同じ幅でレイアウトするのではなく、ものによっては少し広めにしたりページの最大幅まで広げたりしたいという場合に、どのように実装すべきかという話。

この記事は、2022年10月28日に開催されたDIST.37「マークアップな夜」での発表「マークアップのわかり方」をもとにしたものです。当日は話せなかった内容も大幅に追加しています。

複数の要素を重ね合わせるためには、従来、position: absoluteを使うことが多かった。親要素にposition: relativeを、その子要素にposition: absoluteを設定するというもの。

複数のボタンを横並びにしつつ、それぞれのボタンが同じ幅になるように合わせたいということがある。ボタンに同じwidthを指定すれば合わせられるが、するとラベルの長さに応じた幅にできなくなる。

僕のプロフィール画像、通称ギザギザを新しく作り直した。SVG化したいなと長らく思っていたけど、そのまま機械的に変換するのもつまらないし、せっかくなのでとマイナーチェンジを施した。

ボタンのラベルが短い場合でも、ボタン自体には最低限ある程度の幅を持たせたいという場合がある。そんなときには、ボタン自体にmin-widthを指定して最低幅を設定する。

テキストの行の末尾にアイコンを付随させるというレイアウトがある。

この記事は、Jeremy Keith氏による「Declarative design systems」の日本語訳です。掲載に当たって著者の許諾を得ています。

この記事は、Jeremy Keith氏による「Declarative design」の日本語訳です。掲載に当たって著者の許諾を得ています。

後日追記: このやり方の改良版をブログ「ブロックエディタ用のCSSを参考にした、よりよいコンテナの実装」として書いた。

これについて超絶走り書きで簡単に返すのでお許しください。

後日追記: WEB+DB PRESS Vol.133でさらに詳しく書いた。

このウェブサイトをリニューアルした。これまでも何度かリニューアルを重ねてきており、今回でバージョン6ということになる。サイトとしては今年で7年目。

後日追記: このブログの内容を再考して「Tailwind CSSで引数のあるMixinのような仕組みを作る方法（改）」として書き直した。

なにか気になったウェブページを保存したいというとき、以前ははてなブックマークを使っていた。たぶん2017年くらいまで。

少し前に担当したウェブサイト制作の案件で、Utopiaというツールを使ってみた。Utopiaを使うと、ビューポートの幅に応じて流動的に変化するフォントサイズとスペーシングの値のセットを生成できる。

昔から梅が好きでよく食べる。実家にいたころは、口寂しくなるたびに冷蔵庫を開け、おやつ感覚で梅干しを食べては、塩分の摂りすぎだからやめろと母親に言われていた。ご飯を食べるときにもよく梅干しをおかずにしていた。

日本語の文では、文末に到達するまで話の方向性が読み切れないことがある。文を読むときに、途中まで読んだところで「あー、はいはい」となっていても、最後まで読み進めると「あれ、そういう話？」という感じになり、流れを読み誤っていたことに後で気づく。人がしゃべるのを聞いているときにはより顕著になる。しゃべる速度は読む速度よりも遅いので、どうしても焦ったくなってしまうものだ。

いつからかそういう癖がつき始めた。なんでもかんでもを「そのまま」書くわけにはいかないからという意識からなんだけど。散歩してるとかシャワーを浴びてるときみたいに、頭が暇な時間がありすぎると、考えがそっちの方向に進みすぎて、ざっと記事化するには手に負えない感じになってしまうことがある。ちょうどいい抽象度で書きたいことをドンピシャで書けるようなタイミングもあるんだけど、そういうときって今みたいな「まだそのときじゃない」と見送ってきたピースがちょうど繋がったときでもあるかもしれないな、ということに、今まで書いていて気づいた。しかしそれを感じるタイミングは割と頻繁にあって、「このタイミングは本当にマジのやつか？」があまりわからない。いやあるいは、あるテーマを考え終えるとき、別のテーマに頭が移っていく前のタイミングというのが、自分の中で一番満足するまで考え切ったタイミングだ、と言えるだろうか。それがマジのやつだろうか。

Slackのようなインターフェースを見ると、さも人と人が対面してしゃべるような言葉のやり取りがそのままできて、コミュニケーションとして成り立つと思ってしまうことがある。非常に限定的な状況においては可能かもしれないが、たいていはそうならない。

いま住んでる部屋が結構ボロいので、いろいろ不満があって、引っ越したいなあと思いつつも、めんどくさくてずっとほったらかしていたけど、そろそろ本当にどうにかしたいと思って引っ越し先を考え始めた。

とんかつ屋。隣には、神経質そうな思春期の息子と、大雑把そうな年配の父親。

3は極端かもしれない。6くらい。

友人の腹筋ローラーの力を信じろさんと共に監訳を担当した書籍『Every Layout——モジュラーなレスポンシブデザインを実現するCSS設計論』が出版されます。現在、Amazonで予約受付中です。当初の予定よりもかなり遅れてしまいましたが、内容はいまだ鮮やかなままに思えます。

ブログを書くのはおよそ8ヶ月ぶりになる。僕にとっては、それなりに長らく書かなかったことになる。

margin-bottomではなくmargin-topを使う派である旨をツイートしたら理由を尋ねられたので、それに対する回答です。大きくは次の3つです。

丸2日くらいかけて、このサイトのHTML/CSSやサイト生成の仕組みを全部書き直した。わかりやすい変化としては、以前のバージョンではフォントサイズとか余白とかがビューポートのサイズに関わらずつねに一定だったところが、今のバージョンではビューポート幅にもとづいたファクターに応じてすべてのフォントサイズが変化するようになっている。

「歩行 Advent Calendar 2020」を作ったけど、25日中15日しか歩行できなかった。作った当初は本当に25日分全部埋める気でいたけど、実際のところ3日目でいきなり穴を開けてしまっているし、この60%という微妙な達成度が僕の緊張感のなさを絶妙に体現しているようで、なるべくしてなった気がした。

「JavaScript sprinkles in Basecamp turned Stimulus」より。Stimulusの設計意図を理解できる貴重な資料なのでまとめた。

ウェブサイトのソースファイルはファイル形式にもとづいてディレクトリ分けされている場合が多いと思う。たとえば次のように。

個人的な話、Twitterにいろいろと長文も書いたりするようになってからブログをあまり書かなくなった。タイムラインのツイートはすぐに流れていく分、今パッと思いついた話とか、まだ十分整理されてないようなテキストを出しやすい。