「3種類」で管理するReactのState戦略
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Stateのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが開発・運用しているアプリケーションのState戦略についてご紹介していきます。 全体像 アプリケーションに存在する状態（State）を以下の3種類に分類し、それぞれのやり方で管理しています。 サーバーデータのキャッシュ Global State Local State 1. サーバーデータのキャッシュ 「SPAで管理する必要のあるGlobal Stateって、そのうちほとんどがサーバーデータのキャッシュだよね。それを取り除けたら、管理する必要のあるGlobal Stateってすごく小さくなるんじゃない？」という主張を私が認識しはじめたのが2020年の初旬でした。おそらく
React ステート管理 比較考察 - uhyo/blog
こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント（使用者）で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
DocBaseのフロントエンド改修をどのように進めたか
こんにちは、クレイの阪本です。 もともと外部委託パートナーとしてクレイ案件のお手伝いをしていましたが、気づけば中の人となっていました。 よろしくお願いいたします。 先日、DocBaseはフロントエンド構成を Backbone.js+Coffeescript から React.js+TypeScript へ移行しました。大改修です。 どれくらい大きな変更だったかというと、10万行(2500ファイル)もの変更が行われ、それまでRubyだったはずのリポジトリ代表言語がTypeScriptに替わってしまったほどでした。 なお、2021/3/31のリリースでリニューアルすべてが終了したわけではありません。今後、機能拡張やUI改善をしやすくするための足がかりという位置づけです。 安全にリリースするためテスト期間を多めに取ったこともあり、期間としては1年ほどかかってしまいました。 今回はどのようにリニュ
Reactのprops/contextの使い分け - saneyuki_s log
Reactのprops/contextの使い分け 仕事先でたまたまこれの話になり、個人的に思っていることをまとめた。 公開したのは、時々見かける「どっちを使うべき？」みたいな議論に 自分も混ざりたかった 思うところがあったから. 「とにかくpropsでいい」と自分は考えている。 なによりReactは書き方に詰まった場合に、フレームワークライブラリ固有の事情を考慮して解決するというよりも、実装や設計上の問題が一般的なプログラミングパターンの範疇の発想で解決できるのがよい 前提 以下のように考える React/preact のコンポーネント = 通常のclassや関数 状態を隠蔽して抽象する 最近は冪等性がどうとかReact語るときにあんまりいわなくなったけども.... props = 関数やメソッドの引数（入力） context = グローバル変数（モジュールグローバルな変数） 実装の指針
props のバケツリレーって何が悪いんだっけ - fsubal
#React やってて、props のバケツリレーを何か嫌がる人たまにいるんだけど、自分は props のバケツリレーそのものをそんなに悪いと思ったことがない。 「バケツリレーがつらい」ように見えるコンポーネントの大半はそもそも props の設計がおかしい場合が多く、本当の問題はそっちにあると思っている。 たとえば、次のようなバケツリレーはつらいかもしれない。ここでいう Body はサイドバーとしてフォロワーの一覧を表示し、メインコンテンツとしてフィード一覧を表示するみたいなものを想像して欲しい。フォロワー一覧の中で使う props とフィード一覧で使う props を混ぜて1つの親に渡している状況だ。
Storybook First な開発のススメ
Storybook first な開発とは Storybook での呼び出され方を意識しながらアプリケーションコードを書くことをそのように呼んでいます。 道具に設計がひきづられるのはアンチパターンと言われそうな気もするのですが、コンポーネントのカタログを整備していくことは、コンポーネントが良い感じに再利用可能な形で分離できるということでもあり、やっていくとむしろ正道に近づいていくと思います。 Storybook First のコンポーネント設計や型定義をすると、パーツに限らず Storybook でカバーできる範囲が広がり、ページそのもののサンドボックスを作れます。 そして API がない状態でもデータを使って開発ができたり、特定のスナップショットの再現やタイムトラベルに近いことも可能になるというメリットがあります。 つまり、ただのコンポーネントカタログとしてではなく、開発のためのサンドボ
useCallbackはとにかく使え！ 特にカスタムフックでは - uhyo/blog
Reactには、パフォーマンス最適化のためのAPIがいくつかあります。具体的にはReact.memo、useMemo、そしてuseCallbackです。 React.memoで囲まれた関数コンポーネントは、propsが以前と変わっていない場合に再レンダリングが抑制されます。 また、useMemoやuseCallbackは、関数コンポーネント内での値の再計算を抑制する効果を持ちます。 これらは最適化のためのツールなので、「過度な最適化」を避けるように啓蒙する言説がよく見られます。 すなわち、ちゃんと本当に最適化のために必要なところにだけこれらを使おうということです。 特に、React.memoはpropsが以前と変わっているかどうかを判定するためのオーバーヘッドがあるし、useMemoやuseCallbackもフック呼び出しのオーバーヘッドがあります。 意味がないところでReact.memo
React Context を export するのはアンチパターンではないかと考える | stin's Blog
Context を export するなみなさんは React Context を使っていますか？非常に便利ですよね。 え、使ってない？みんな React Context 使っとる。使ってへんのお前だけ。 冗談はさておき、この記事では Context を export するなという内容をお話しします。 React Context とはその前に React Context についてざっと解説していきます。 Context は、コンポーネントをまたいだ値の共有を実現するためのオブジェクトです。 createContext で生成することができます。 import { createContext } from "react"; const context = createContext<string>("initial value");
READYFOR主催のフロントエンド勉強会【実践！フロントエンド分離戦略】を開催しました！ - READYFOR Tech Blog
2021年2月5日に、READYFOR主催としては初となるオンライン技術勉強会、【実践！フロントエンド分離戦略】を開催しました！本記事では、当日の様子と各セッションの内容を振り返ってみたいと思います。 readyfor.connpass.com 当日は実に最大240人を超える視聴者が参加してくださり、Twitterでもご好評の声をいただきました。当日の様子はこちらのTogetterでも空気感が感じられると思うので、ぜひご覧になってみてください。 togetter.com 1. READYFORのフロントエンドを2019年末から全体像を構想してどうしていくか検討した話 まずはフロントエンドチームのエンジニアリングマネージャー岡村（@resqwork）による、「READYFORのフロントエンドを2019年末から全体像を構想してどうしていくか検討した話」です。 2019年8月に岡村がジョイン
React.Context で作る GlobalUI Custom Hooks
GlobalUI を、React.Context を利用して作る TIPS です。どの Component からも利用しやすい様に Custom Hooks を経由します。何かを更新した際、画面上部に通知を表示する（Notification）よくあるサンプルを元に解説します。（↓ の画像の様なもの） Custom Hooks 利用例 Notification を呼び出す Component は次の様なコードになります。showNotification関数に任意の文字列を与え表示する、というシンプルな作りです。 export const Example = () => { const { showNotification } = useNotificationDispatch(); const handleClick = () => { showNotification("更新しました");
フロントエンドの複雑さに耐えるため実践したこと / readyfor-nextjs-first
【READYFOR】実践！フロントエンド分離戦略::発表資料 https://readyfor.connpass.com/event/198730/
hygen で生成 - 対話形式の Component 雛形 -
Component 作成にあたり、storybook や test も一度にコミットする場面が増えてきました。そして CSS Modules や、特定 Component 専用の custom hooks など、一つの Component を構成するファイル群はそれなりの量になってきます。例えば、以下の様な module 構成の Component です。これを手作業で作成するとなると、少し億劫になりますよね。 └── atoms └── Button ├── Button.stories.tsx ├── Button.test.tsx ├── Button.tsx ├── dependencies.ts ├── index.tsx └── style.module.css 作成時にButtonという名称だけ決めてしまい、CLI から雛形出力できれば、作業効率向上が見込めます。（story
Presentational and Container Components
BismuthUpdate from 2019: I wrote this article a long time ago and my views have since evolved. In particular, I don’t suggest splitting your components like this anymore. If you find it natural in your codebase, this pattern can be handy. But I’ve seen it enforced without any necessity and with almost dogmatic fervor far too many times. The main reason I found it useful was because it let me separ
blitz-js prisma rails 倒し方
この記事の内容 blitz-js が生まれた背景 prisma の紹介 blitz で簡単なブログを作ってみる blitz を vercel にデプロイしてみる tldr blitz-js は next.js + prisma で rails を再現しようとしているフレームワーク Prisma ORM それ自体が良い。blitz の理解のためにも、まず Prisma を学べ blitz-js 自体はまだ α 品質だけど、今から注目しておく価値はある。デファクトになるかは不明。思想は継承されそう。 はじめに next.js はとても良いフレームワークだが、永続層を持たない。なのでフロントエンドとフロントサーバーに閉じている。 永続層、つまり DB を持たないので、初学者や流行りのプログラミングスクールの教材に選ばれない。また、JavaScript の学習資料が散らばっている。 要は Rail
TypeScript + React: Why I don't use React.FC
Published on July 30, 2020 Stefan on Mastodon Reading time: 10 minutes More on TypeScript, React, Preact Update: React types for version 18 changed a lot! If you encounter problems described in this article, make sure you update to the latest version! In my recent article on TypeScript and React component patterns I’ve stated that I don’t use the built-in type React.FC<> but rather be explicit wit
UIが嘘をつく？ UXデザインにおける「楽観的な更新」とSPAでの作り方 - カミナシ エンジニアブログ
こんにちは、デザインエンジニアのショウです。 突然ですが、UI/UX デザインにおいて、「楽観的な更新」という言葉を聞いたことがありますか？あまり聞いたことがなくても、実は日常にたくさん存在しています。 例えば、 twitter や facebook のいいねボタン。いいねをタップした直後に色がつくのですが、実はサーバーへのリクエスト送信と UI 上のいいねの色付きが同時に発生しています。つまりサーバーからの通信結果待たずに UI を更新しています。 他に、trello でタスクカードを隣の列に移動したり、iMessage や Facebook メッセンジャーでのメッセージの送信、Kindle アプリで途中までしかダウンロード出来てない本が読めることなども楽観的な更新です。 図：楽観的な更新を採用しない時と採用した時のメッセージ送信のUI （引用元） 楽観的な更新の意義 早くも 1968
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
より速い WEB を目指す Next.js / nextjs-make-the-web-faster
Building Modern Applications with Next.js and MongoDB | MongoDB
The Fault in Our Tolerance: Accounting for Failures in React