Harajuku.ts Meetup 〜 Recoilの事例集めました〜
2023年1月20日 Harajuku.ts Meetup 〜 Recoilの事例集めました〜 にて発表した資料です。
以前、Next.jsのスクロール位置復元について記事を書きました。 上記記事でSPAとMPA(Multi Page Application)における、ブラウザバック/フォワード時のスクロール位置復元について言及しました。 MPAではスクロール位置がブラウザによって復元されることがある(ブラウザの実装に依存) SPAではこれらが軽視されがち Next.jsにおいても、デフォルトでは復元されない(ChromeでSSGページなど一部条件下では復元される) Next.jsではexperimental.scrollRestorationを有効にするとスクロール位置をsession storageに保存し復元する これらと同様に、ブラウザバック/フォワード時のUI復元についても軽視されがちなものの1つです。最近もこの手のUI体験の悪さについて、問題提起がされ話題になりました。 ブラウザバック/フォワー
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Stateのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ! この記事では、今わたしが開発・運用しているアプリケーションのState戦略についてご紹介していきます。 全体像 アプリケーションに存在する状態(State)を以下の3種類に分類し、それぞれのやり方で管理しています。 サーバーデータのキャッシュ Global State Local State 1. サーバーデータのキャッシュ 「SPAで管理する必要のあるGlobal Stateって、そのうちほとんどがサーバーデータのキャッシュだよね。それを取り除けたら、管理する必要のあるGlobal Stateってすごく小さくなるんじゃない?」という主張を私が認識しはじめたのが2020年の初旬でした。おそらく
ReactはじめSPAのStateは大きく2種類、Local State・Global Stateの2種類でおおよそのStateの分類が可能であると考えていました。これに対し会社の先輩から意見をもらって、以下2点に気づきました。 Global Stateには大きく、Client StateとServer Stateの2つがある Stateにはライフタイム(生存期間)が存在し、Client Stateにはスコープ的Globalと時間的Globalの2つが含まれている これらを意識すると、自分はStateの実装を結構感覚的にやってしまっていたなと気づいたので、Stateの分類について改めてまとめてみようと思います。Reactで何かしらのStateを実装する時に、本稿の分類が実装の参考になれば幸いです。 スコープによるStateの分類 まずこれまで自分が認識してたスコープにおけるStateの分類
Presentational components like Avatar, Button, and Tooltip receive inputs exclusively via props and have no internal state. This makes it straightforward to isolate and write stories for them. However, components higher up in the application tree are trickier to build in isolation with Storybook. Connected components like Forms, List, and Cards track application state then pass behaviours down the
こんにちは。LINEフィナンシャル開発センター フロントエンドエンジニアの峯です。 先日新卒としてLINE証券プロジェクトに配属となり、最初のタスクとしてRecoilによる状態管理の導入に取り組みました。 その際、なぜRecoilにしたのか、また本番開発にRecoilを使うにあたって設計に気をつけたことなどを本記事でご紹介しようと思います。 技術選定 いままでの状態と課題 LINE証券フロントエンドではReact+Typescriptによる開発を採用しており、いままでのグローバルな状態管理にはUnstated を用いていました。 Unstatedでは Container classを状態の単位とし、その内部の stateを setState によって更新します。状態を使用したいコンポーネント側では、<Subscribe> コンポーネントによって情報を読み出すことができます。 一方ご存知の通
The new wave of React state managementUnderstand the core problems state management libraries need to solve. And how the proliferation of modern libraries address them in new ways. IntroductionAs React applications grow in size and complexity, managing shared global state is challenging. The general advice is to only reach for global state management solutions when needed. This post will flesh out
ReactアプリケーションではProviderタワーがよく見られます。Providerタワーは、アプリの上の方で次のコードのように複数のProviderが積み重なっている状態のことです(一般的な呼称かどうかは知りません)。 const App: React.FC = () => { return ( <FooProvider> <BarProvider> <BazProvider> <MainContents /> </BazProvider> </BarProvider> </FooProvider> ); }; Providerは、コンテキストに対して値を供給する役割を担っており、コンポーネントツリー内でProviderより内側に配置されたコンポーネントからはそのコンテキストの値を参照することができます。コンテキストは、Reactにおいて外部ライブラリを使わずにステート管理(特にアプリ
昨日、Facebook製のReact用ステート管理ライブラリRecoilが発表されました。Facebook製といってもReact公式のステート管理ライブラリとかそういう位置付けではないようですが、それでも大きな注目を集めているのは間違いありません。 そこで、筆者がRecoilに対して思ったことや、筆者の視点から見たRecoilの特徴を記事にまとめました。 なお、この記事の執筆時点では副作用の扱いなどの点はいまいち情報が揃っていません。この記事では速報性を重視し、コアのステート管理部分に絞って考えています。また、まだexperimentalなライブラリなので、今後この記事の内容からRecoilのAPIが変化したとしても悪しからずご了承ください。 この記事を書くときに筆者が色々試していたCodeSandboxはこちらです。 https://codesandbox.io/s/recoil-san
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く