はてなブックマーク

はじめに フロントエンド開発において、効率的かつ一貫性のあるモック生成は非常に重要です。本記事では TypeSpec、Orval、Storybook の 3 つのツールを使用して自動生成でモックを実現する方法を紹介します。 TypeSpec は、大規模な API を提供するために Microsoft が開発し、使用している新しい API 記述言語です。 Orval は、OpenAPI 仕様から TypeScript のクライアントコードを生成するツールです。これにより、最新の API 仕様に基づいたクライアントコードを常に保持し、API との通信がスムーズに行えるようになります。 Storybook は、コンポーネントを独立して開発・テストするためのインタラクティブなツールです。コンポーネントの見た目や動作を個別に確認できるため、UI の一貫性を保ちながら効率的に開発を進めることができます

React Router とは React Router のルートのマッチング React Router のドキュメントのRanking Routesのセクションを例として説明します。 以下の 5 つのパスパターンを取り得るアプリケーションがあるとして、/teams/newというパスが与えられたときに、どのパスパターンがマッチするでしょうか。 [ "/", "/teams", "/teams/:teamId", "/teams/:teamId/edit", "/teams/new", ]; React Router はここからさらにルートをランク付けし、最終的に/teams/newを最もマッチするルートとして採用します。 どのようにルートをランク付けするか ランク付けというのは、ルートがどれだけパスにマッチするかを評価することです。React Router は、ルートのパスパターンと与えら

shiki とは何か shiki は、VS Code のシンタックスハイライトと同じエンジンである TextMate の文法とテーマをベースにした、高度なカスタマイズが可能なシンタックスハイライターです。 Astro でも内部で使われていたり Node.js のWebsiteでも使用されていたりします。 この記事では、shiki の使い方や特徴について紹介していきますが、とりあえず試したい方は公式ドキュメントにPlaygroundが用意されているので使ってみるのもいいかもしれません。 前提： この記事の情報はv.1.2.0の公式ドキュメントを参考にしています。 shiki の名前の由来は？

ファンタラクティブのエンジニアの 太田 です。 Buttonコンポーネントのwidthの考え方について書きます。 よくあるSize定義 Buttonコンポーネントのサイズの定義でこのような定義がされているのを時々目にします。 UIライブラリでも同じような定義が使われていた気がしますが、最近はあまり見かけなくなったように感じています。 この定義方法はやめた方がいいのではと思っています。 問題点 width、height、テキストのサイズなどが同一のpropで制御されている widthが固定サイズ width、height、テキストのサイズなどが同一のpropで制御されている 高さやテキストのサイズはsmがいいけど、widthだけ変えたい場合に対応できません 対応方法 widthをsizeから分離する widthが固定サイズ デバイスサイズによって見え方が違う どのデバイスで見たときもデバイス

ファンタラクティブのエンジニアの 太田 です。 OpenAPIスキーマで定義したレスポンスに対するexampleをmswとstorybookでも使用してAPIスキーマで想定したレスポンスをStorybookで確認できるようにする試みについて紹介します。 やりたいこと OpenAPIスキーマで定義したexamplesを参照してmswでAPIモックを定義、定義したAPIモックをstorybookで使用 嬉しいこと APIで想定したレスポンスに対してフロントの挙動をStorybook上で確認できるのでAPIとフロントの認識のずれが改善されます。 エラーの表示や、権限によるUIの出し分けなど大変な確認を、APIスキーマで定義した内容を網羅する形でStorybook上で確認できます。 逆にAPIスキーマに定義されていないものはStoryを作らないので、確認するべきものはすべてAPIスキーマで定義しま

ファンタラクティブのエンジニアの 太田 です。 InternetExplorerのサポートが終了した現在、cssでflexboxを使わない理由はなくなったと思います。 flexboxでgapを使うべきか考えました。 (gridではいくらでも使えばいいと思ってます。) gapとは 要素間の余白を定義するプロパティです。 gapのメリット 要素間が同じ余白のサイズであれば、親要素にgapを指定するだけで、要素間の複数のmarginを書かなくてよくなる。 カラム落ちの余白を気にしなくていい gapを使うべきパターン カラム落ちを考慮する必要があるレイアウト 横並びで1行の要素数が画面サイズによって決まるようなレイアウトではgapを使うことを検討できます。 marginを使用した場合はきれいに並べようとすると非常に複雑な計算が必要となり、状況によっては実現不可能な場合もあります。 gapを使えばと

ファンタラクティブのエンジニアの 太田 です。 Reactのコンポーネント定義にReact.FCを使うのをやめたことについて書きます。 背景 ファンタラクティブでは最近までReactをあまり使っていませんでした。 Vue (とくにNuxt) で開発を行うことが多かったのですが、VueやNuxtのバージョンアップのコストなどを考慮しReactでの開発を積極的に始めました。 それまで社内でReactの知見がなかったので、設計や実装について様々な検討をし、コンポーネントを作成する際にReact.FCはいらないのでないかという結論に至りました。 (VFCも同様です) なぜFCをやめたか Genericsが使えない (使いづらい) たとえばセレクトボックスの汎用コンポーネントを作成する際、選択値にgenericsを使いたいことがあります。 type SelectProps<T extends num

ファンタラクティブのエンジニアの 太田 です。 デザイナーさんに向けてDefensive CSSについて書きます。 Defensive CSSについて 簡単にいうと予期せぬレイアウト崩れを防ぐ (減らす) CSSを書くという概念です。 詳しくは本家のサイトに書かれています。 本家のサイトにも書かれていますが、これはCSSだけでなくUIデザインにも適用される概念です。 自分自信エンジニアとして様々なプロダクトに関わってきて、大小あれどほぼすべてのプロダクトで課題となり、考慮が不十分なデザインをエンジニアがよしなに実装しているのをみています。 「全て指示されないと実装できないなんて」「エンジニアのためにデザインしているわけじゃない」という意見も見かけますが、あらゆることを考慮した上であえてルールから外れたデザインを作ることと、ただデザインの考慮が足りないだけでは全然違うと思っています。 この記

ファンタラクティブのエンジニアの 太田 です。 Optimistic Updateについて検討する機会があったので紹介します。 SPAでAPIを利用しデータを更新しその結果を画面に反映させる場合、APIのレスポンスを待つ必要があります。 しかし、レスポンスを待ってから画面に反映すると、ユーザーが操作してから画面に反映されるまでに時間がかかり、UXが悪くなってしまいます。 そんな悩みを解決するのがOptimistic Updateです。 課題 ユーザーの操作によりデータを更新し、その結果が返ってくるまで1秒かかるとしたら、1秒以上経ってから画面に反映されるため、もっさりしたシステムに感じます。 1秒ならまだマシですが、これがもっと長かったらどうでしょう。 またデータ更新後、別のデータ取得APIを呼び出して更新したデータを再取得する仕組みになっているかもしれません。 その場合、それぞれのAPI

ファンタラクティブのエンジニアの 太田 です。 数値入力コンポーネントを作成する際に type="number" を使用するのをやめたことについて書きます。 input[type="number"]とは input[type="number"] (PC) input[type="number"] (スマホ) 数値を入力するためのinputで半角数値以外の入力を除外する 問題 validな数値しか受け付けない 数値以外の値が入力できないためTypeScriptでも扱いやすくよさそうに思えますが、使用するユーザーは戸惑うことがあるようです。 実際にあった問い合わせや、問い合わせから想像する状況は以下のようなものです。 入力できない (全角入力してる) 確定したら値が消えた (全角入力してる) ペーストできない (全角でペーストしてる) キーボードではなく、UI上の▲▼で入力しないといけないと思

ファンタラクティブのエンジニアの 太田 です。 Next.js v12.1でリリースされたOn-demand ISRについて、SSRの代わりになり得るのか考えました。 SSRとは ユーザーがページアクセスするたびに、サーバーサイドでデータ取得をしプリレンダリングした結果をクライアントに返す 常に最新のデータを取得できる 動的ルーティングのOGP対応が可能 SSR ISRとは ページアクセス時にキャッシュされた静的なページを返しつつ、キャッシュ有効期限が切れている場合は裏でキャッシュの再生成をし、次回アクセス以降に使用できるようにする SSGと違いページの更新にビルドが必要ない ISR キャッシュ生成 On-demand ISRとは ISRに追加で任意のトリガーでキャッシュの更新をすることができる On-demand ISR キャッシュ生成 ISRとOn-demand ISRの比較 ISR