Storybook First な開発のススメ
Storybook first な開発とは Storybook での呼び出され方を意識しながらアプリケーションコードを書くことをそのように呼んでいます。 道具に設計がひきづられるのはアンチパターンと言われそうな気もするのですが、コンポーネントのカタログを整備していくことは、コンポーネントが良い感じに再利用可能な形で分離できるということでもあり、やっていくとむしろ正道に近づいていくと思います。 Storybook First のコンポーネント設計や型定義をすると、パーツに限らず Storybook でカバーできる範囲が広がり、ページそのもののサンドボックスを作れます。 そして API がない状態でもデータを使って開発ができたり、特定のスナップショットの再現やタイムトラベルに近いことも可能になるというメリットがあります。 つまり、ただのコンポーネントカタログとしてではなく、開発のためのサンドボ
Promise のキャンセルについて - Qiita
[ English version ] JavaScript と Node.js についてのこの徹底した投稿では、Promises のキャンセルの歴史、なぜNode.jsに関係があるのか、そして async/await APIで使おうとしたときに注意すべきことについて学ぶことができます。 この投稿は、JavaScript の Promise API をよく理解していて、 Node.js の経験がある方のためのものです。 歴史 2014 年に Promise API がブラウザに導入されて以来、人々は Promise で他に何ができるかを調べていました。ブラウザに最初に登場した関連APIは、HTTP リクエストのための fetch() でした。 HTTP リクエストの問題は、サーバーのリソースを消費することであり、サーバーに送信されるリクエストの数が多い場合はお金がかかります。このため、特に
SWR vs React Query - fsubal
#フロントエンド （※ この記事は API およびそこから導かれる設計のしやすさ観点での比較をしています。実際にキャッシュが有効に効いたか、などについてはまた別の機会に ） 動機 SPA の状態管理に必ずしも Redux いらないんじゃね問題 Redux が嬉しいのってクライアントサイドでモリモリ状態が変わる画面だけじゃん、みたいなアレ 検索結果の一覧みたいなページに Redux を使うの意味なかった 本当に必要なとこだけ使うようにしたい ほとんどのケースで欲しいのって React 向けの API クエリキャッシュ これまでは Redux の Store を単なるキャッシュとして使ってたが、違うよね 候補 ↑ みたいな話でよく上がるオルタナティブとして SWR と React Query がある これら 2 つを比較する。 TL;DR SWR の方が王道感を感じるけど、思ったより #rea
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
