はてなブックマーク

Tailwind CSSにおいて、スタイルの組み合わせを抽象化したいと考えたとき、対処としてはいくつかの方法が考えられる。 もっとも一般的なのは、コンポーネントやパーシャルとして、クラス属性値とHTMLをセットで抽出する方法。 <template> <div> <img class="rounded" :src="img" :alt="imgAlt" /> <div class="mt-2"> <div> <div class="text-xs font-bold uppercase tracking-wider text-slate-600">{{ eyebrow }}</div> <div class="leading-snug font-bold text-slate-700"> <a :href="url" class="hover:underline">{{ title }}</

JavaScriptにおいて、ある配列をもとにして別のオブジェクトを作成する場合、Array#reduceを使用することが多い。 const input = ['foo', 'bar', 'baz']; const result = input.reduce((accumulator, currentValue) => { accumulator[currentValue] = capitalize(currentValue); return accumulator; }, {}); assert.deepStrictEqual(result, { foo: 'Foo', bar: 'Bar', baz: 'Baz' }); しかし例のように、単にキーと値の組み合わせにマッピングするだけなら、あえてArray#reduceを使うまでもない。代わりにObject.fromEntriesを使え

複数のボタンを横並びにしつつ、それぞれのボタンが同じ幅になるように合わせたいということがある。ボタンに同じwidthを指定すれば合わせられるが、するとラベルの長さに応じた幅にできなくなる。 縦方向に並んだボタンであれば、いずれか幅の広い方に合わせることは難しくない。次のようにすれば、最も幅の広いボタンに合わせて他のボタンも配置することができる。 <div class="wrapper"> <button type="button">Hi</button> <button type="button">Hello</button> <button type="button">Lorem ipsum dolor</button> </div> .wrapper { display: flex; flex-direction: column; gap: 1em; width: fit-conten

ReactのUIコンポーネントライブラリを使っていると、あるコンポーネントによってレンダリングされるHTML要素の種類を変更したくなる場面がある。たとえば、通常はbutton要素としてレンダリングされるButtonコンポーネントを使うときに、代わりにa要素を使ってレンダリングしたいというケース。 as prop そのような場合、一般的には、Buttonコンポーネントにas propを実装して対処することが多い。 function Button({ as: Component = 'button', ...props }) { return <Component {...props} />; } render( <> <Button type="button"> I’m a <code>button</code> element </Button> <Button as="a" href="

後日追記: このやり方の改良版をブログ「ブロックエディタ用のCSSを参考にした、よりよいコンテナの実装」として書いた。 CSSにおいて、コンテナと呼ばれるパターンがある。たとえば次のような実装を指している。 .container { box-sizing: content-box; margin-right: auto; margin-left: auto; padding-right: 1.25rem; padding-left: 1.25rem; max-width: 60rem; } この実装の特徴は、ビューポートの幅が広いときには要素の内容物が中央揃えになり、狭いときには左右に最低限の余白を残しつつ縮むことだ。 よくある使い方としては、このコンテナでページの外側の方を囲いつつ、その中に雑多に要素を配置していくことになる。 <div class="container"> <h2><!

なにか気になったウェブページを保存したいというとき、以前ははてなブックマークを使っていた。たぶん2017年くらいまで。 しかし当時のそのインフラ的な事情か、ブックマークをしようとしてもエラーが発生してできない場面が頻発していた。いや、実際そこまでの頻度ではなかったのかもしれないが、僕がそこそこヘビーユーザーだったために出会す機会が多かった気がする。いずれにせよ、それが嫌になって徐々にはてブを使わないようになっていった。 代わりに、気になったページはTwitterでシェアするようになった。自分用ブックマークを兼ねたシェア。ツイートはすぐに流れていってしまうので記録にはならないと考えるのが普通だと思うけど、僕の場合は、自分の過去のツイートを検索して見つけるという使い方をしてきた。 たとえば、「Buttons shouldn’t have a hand cursor」みたいな記事があったなと思え

margin-bottomではなくmargin-topを使う派である旨をツイートしたら理由を尋ねられたので、それに対する回答です。大きくは次の3つです。 末尾の要素の存在が任意である場合が多いため Stackレイアウトとの取り合わせやすさのため 隣接セレクターを使った場合分けができるようにするため CSS、基本コンポーネントの上にマージン取る派と、下にマージン取る派がいると思うですけど、自分は今までずっと下で。というのは、その方が直感的だと感じるからなんですけど、見出しの下って結構縮めるよね？それを上マージンでやると結構頭こんがらがらない？って思うんだけどどうなんだろう — Takazudo (@Takazudo) January 12, 2021 上です — 全部入りHTML太郎 (@_yuheiy) January 12, 2021 なぜですか? — u (@uknmr) Januar

「JavaScript sprinkles in Basecamp turned Stimulus」より。Stimulusの設計意図を理解できる貴重な資料なのでまとめた。 DHHにとってプログレッシブエンハンスメントとは、コンテンツのプログレッシブ性を実現するためというよりは、アプリケーション開発のための道標のようなもの。ベースとしてのHTMLはまずサーバーに生成させて、動的部分としての少しの差分をJavaScriptに扱わせる。BasecampやGitHubのように動的部分の少ないアプリケーションにとってはそれが適切なやり方。React/ReduxやAngular、そのほかクライアントサイドのMVCフレームワーク等を試してきたが、それによってプロダクトのコードが良くなることはなかった。 BasecampにあるJavaScriptを調査して、どのような慣習があるか、それを踏まえてどのような

個人的な話、Twitterにいろいろと長文も書いたりするようになってからブログをあまり書かなくなった。タイムラインのツイートはすぐに流れていく分、今パッと思いついた話とか、まだ十分整理されてないようなテキストを出しやすい。 アイデアをTwitterに書きやすいのは取り返しがつかないからだと言ってる人がいた。まず最初のツイートをすると、それが少なくとも何人かに読まれてしまった事実は取り返しがつかなくなるので、その責任の引き受けから連鎖してほかのものも書けると。その話を読んで、ツイートはリアルタイムにしゃべることに似ている気がした。一度しゃべり始めてしまった以上は、とりあえず着地するまではしゃべりを続けないといけないというのと似ている。 そうしたとりあえずのものがツイートとして消化されてしまうとすれば、ブログを書くためには「あえて」そうする動機が必要になってくる。「あえてのもの」は即席じゃない

ウェブサイト（not ウェブアプリケーション）のためのフロントエンド開発スターターキット。 ウェブアクセシビリティの参考資料をまとめたサイト。日本語の資料を中心にリンク数は200を超える。サイトのデザインおよび実装に携わる。有志のメンバーにより制作・運営されている。 自社で所属していたチームのウェブサイト。 過去に更新していた個人ブログ。 昨今、特にフロントエンドのアプリケーションにおいて、技術的な役割よりもフィーチャー（feature）を起点としてディレクトリを構成する（package by feature）というする考えが一般化しつつある。たとえば、技術的な役割を起点としたディレクトリ構成（package by layer）は次のようなものだ。 このサイトの名前を「Yuhei Yasuda」から「yuheiy」に変更した。「Yuhei Yasuda」だと人名そのままだからサイト名っぽく