CSS Modules で作る SVG Icon Component
この<Icon />コンポーネントを使用すると、以下キャプチャのようになります。 UI ライブラリから提供されているものを使用する選択肢もありますが、デザイナーが用意した SVG を使用する場合は自作する必要があります。自作<Icon />コンポーネントのフォルダ構成は、概ね以下のようになるでしょう。 SVG Icon Component をどう作るか アイコン画像を背景画像ではなく SVG にする理由は「塗り色」を動的に変更したいためです。新色を追加するとき、全種のアイコン画像を追加するのは大変です。SVG であれば、要素に対しpath { fill: #ff0; }のように CSS 指定をすることで動的に塗り色を変更できるため、このようなケースでは「インラインレンダリング」が選択できます。インラインレンダリングであれば、塗り色だけでなくサイズも動的に変更できます。 ただし、インラインレ
テスト優先度をあげたくなる実話 - フロントエンド版 -
Storybook・テストに関して「メンテナンス工数に見合うだけのメリットがあるか？」という議論を、経験したことはないでしょうか。フロントエンドは、とにかく動くものを作ることが優先され、Storybook・テストが二の次になっている現場も少なくないと思います。 限りある工数を割きチームで取り組むものですから、導入するためには「どういったメリットがあるのか？」という具体的な例をチームに示す必要があります。これは今年、筆者が体験した実メリットのお話です。導入を躊躇している現場にむけ、参考になればと思い書きました。 【Storybook】不要な Global CSS を削除できた きちんとコンポーネント設計され、コンポーネントに閉じた指定をしていたとしても、どこかに必ず Global な CSS があると思います。何かしらの資材を受け継ぎ立ち上げたプロジェクトに関しては、Global な CSS
AtomicDesign 境界線のひき方
AtomicDesign はコンポーネント粒度の指標として共有し易く、多くのプロジェクトで採用されています。しかしながら、その設計概念が先立ってしまい、いくらかの課題を抱えている場合があります。 1.影響範囲が特定しにくい 2.依存関係が特定しにくい 3.汎用性が低くなりがち 4.汎用性の高低が判別できない 多くの場合「粒度」だけを基準にしてしまい、横断的コンテキストに「早期区分」 してしまっていることが直接的原因です。 「関心範囲の広さ」区分 アプリケーションを構成するモジュールは「関心範囲の広さ」で区分を行うことが鉄則です。次の２つのhelper.tsを見てください。全く同じ関数が定義されていたとしても、どこで利用される想定のものなのか、すぐに判別できますね。utilsは、プロジェクト内で横断的に再利用される可能性が高い（関心範囲が広い）ものが集約されます。 AtomicDesign
useSWR で作る Form 画面の備忘録
管理画面のような CRUD 中心のプロダクトでは Form と CSR をよく利用します。SWR は開発体験に優れたライブラリですが、Form に利用する場合注意点があるので、備忘録として共有します（広義の SWR と紛わない様に、タイトルはuseSWRとしました） 視覚的安定性とキャッシュ はじめに、SWR や React Query を利用するモチベーションについて言及します。SWR は一意のキーに紐づいたキャッシュが無い場合、loading fallback を表示します。fallback 表示はたとえ一瞬であっても「チカっ」とした表示になるため「スムーズではない印象」を利用者に与えてしまいます。しかし SWR や React Query は有キャッシュ時は fallback を SKIP するため、ユーザー操作を妨げずに視覚的安定性を提供することができます。 このメリットは、反復画
Next.js の状態管理 2020
Next.js といえば、SSG（JAMstack）が最近は特に話題ですね。1年前まではgetInitialPropsを用いて、どう SSR するのかという事が話題の中心でした。Next.js 9.3 以降、SSR をする際にはgetInitialPropsではなくgetServerSidePropsを使用することを推奨すると記載されています。（そして、getInitialPropsを使用することで自動最適化が無効となってしまう旨も）getStaticPropsやgetServerSidePropsを利用することで、私たちは SSG・SSR をページ単位で切り替えることができます。 「SSG・SSR」が共存する可能性がある場合、SSR にはgetServerSidePropsを利用することになります。この変化による影響範囲は多大で、状態管理とデータフェッチについて、再考する必要がでてきまし
Link と ISR が引き起こす Next.js の過負荷
「なんだか Next.js の Static Generate に使っている外部 API 呼び出し回数が多いような？」と思っている方へ。閲覧されもしないページを、ISR（Incremental Static Regeneration）でみだりに再生成していませんか？本稿では、Link コンポーネントの振る舞いと ISG / ISR の組み合わせの際、注意したい prefetch の設定について言及します。 ISG のおさらい ISG（Incremental Static Generation）は、Next.js がオンデマンドでページを静的生成するアプローチです。「オンデマンドで静的生成する」ことで、ビルドタイムの静的生成をスキップすることができます。 getStaticPaths の fallback オプションを true か 'blocking' にすることで発動します。 これは膨大
atoms の「制御・非制御」をどう作るのか
本稿では React で atoms を作る際「制御・非制御」どちら前程に作るべきか？という課題についてを考察します。 「制御・非制御」は atoms では決定しない なぜ決定しないのかは「ライブラリ選定に縛られないため」につきます。Form 関連ライブラリはたくさん選択肢がありますが、この選定が atom に影響するのはあまり良いパターンではありません。 「制御・非制御」は atoms では決定しないといっても、正確には以下の「A・B」のうち 「A」で決定しない という意味です。以下「A・B」の様にきちんと分けて構成することで「A」は「制御・非制御」に囚われず、再利用することが出来ます。 A. 【"style"決定層】CSS のみが適用された element 集 B. 【"制御・非制御"決定層】A を用いて、再度小さい atom を構築する CSS in JS 以外での定義 CSS in
MSW で加速するフロントエンド開発
みなさん、フロントエンド開発時のモックサーバーは何を使っていますか？モックサーバーといっても様々なアプローチがあると思いますが、最近活用している MSW が便利だったので紹介します。MSW（Mock Service Worker）はブラウザリクエストを Service Worker がインターセプトし、任意のレスポンスを返すことが出来るライブラリです。 次の様な Express 風ハンドラーで、モックレスポンスを表現することができます。なんとこのコードがブラウザで動いてしまいます。 import { setupWorker, rest } from "msw"; const worker = setupWorker( rest.get("https://myapi.dev/csr", (req, res, ctx) => { return res( ctx.json({ title: "C
原子の再定義 - Atomic ReDesign -
Atomic ReDesign とは 「Atomic ReDesign」 は、かの有名な「Atomic Design」の拡張概念です。React や Vue.js を用いたコンポーネント設計において、私たちはしばしば頭を抱えることがありました。UI 粒度の分類制約は、コンポーネント設計最適化を阻むことがあるからです。 「この粒度のコンポーネントはどこに属するものなのか？」という疑問に対し統一された解はなく、プロダクト毎の性質によって定める必要がありました。また、文脈が散在することにより、コードに対する集中力低下を招きました。 Atomic ReDesign は顕在化した 「Atomic Design とアプリケーション設計の乖離」 をとらえ、現実的な設計指針となることを目指します。 Atomic Design とアプリケーション設計の乖離 本家 Atomic Design はデザインシステ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
