from Atomic State Management
差分レンダリング
from Atomic State Management
差分レンダリング
(Type|ECMA|Java)Script #WIP #Stream
Reactive Extensions
親戚でInteractive Extensionsもいる
https://github.com/ReactiveX/IxJS
関数型プログラマのための Rx 入門(前編)
Recoilインスパイアのライブラリ
WeakMapでキャッシュ管理されている
#フロントエンド
#メンタルモデル
推測するな計測せよ
Do it once. Do it right. And, you'll never have to do it again.(一度だけやれ。正しくやれ。そうすれば二度とやらずに済む。)
性能に関する考え方
#状態管理(GUI) #設計 #宣言的UIの設計レシピ
Recoil, Jotai, Riverpodのようなボトムアップ型の状態管理(GUI)アプローチを指す
Opticsや遅延束縛など、関数型プログラミングに多大な影響を受けている
Atomic State Managementのパラダイム
ObservableとSelectorとStreamを扱いやすくしたようなようなモノ
#Data-Flow_Graph #Recoil #Jotai #Rx
/study-react/RxJS の言葉で Recoil を説明する
RecoilとRxJSってどう違うの? 共通点は? 調べてみました!
HotはRecoil > Atom
ColdはRecoil > Selector
#React #設計 #宣言的UIの設計レシピ #コンポーネントツリー
問題解決で最も重要な考え方のひとつ
抽象化とモデリングの違い
困難は分割せよ
https://ja.wikiquote.org/wiki/ルネ%E3%83%BBデカルト
#Recoil Recoil > waitFor* #Atomic_State_Management
waitForAllSettledを利用する
何らかのコールバックの中で手続き的に処理したいときに困るので以下のようなケースで役に立つ
const options = atom(...)
#Jotai
from Next.jsのPrerenderでStorageのReference Errorが発生する際の対策
Storage — Jotai, primitive and flexible state management for React
JotaiとWeb Storageのintegration
#Jotai #TanStack_Query
JotaiとTanStack Queryのintegration
https://jotai.org/docs/integrations/query
Concurrent, Suspenseの文脈でキャッシュ管理と理想的なデータフェッチを考える (Recoil, Aspida, React Query, GraphQL)
#Finite_State_Machine(FSM)
from XState
XState — Jotai, primitive and flexible state management for React
JotaiとXStateのintegration
#Atomic_State_Management
コンポーネントとatomを同じファイルに配置したいという意図
はAtomic State Managementを使い始める当初、atom宣言のファイルとコンポーネントを分離していた
が、コンポーネントとノードは近い位置にするほうが凝集度高いのでいいなと思ってきた
データとロジックは近い位置にまとめる
#技術の審美眼 #Atomic_State_Management #プログラミングパラダイム
from CQRSの時空分割と観測
パラダイム
Render As You Fetchパターン
データフロープログラミング
#プログラミング
メモリ内のリソースの開放を行うもの
これを忘れるとメモリリークが発生する
GUIの状態管理(GUI)の観点でも大事
Recoil, Jotai, Reduxとかはコンポーネントツリーの外にステートを持つので残り続ける
#Jotai
Jotai の selectAtom で状態を固定する
#TanStack_Query #データフェッチ #Jotai
You Might Not Need React Query for Jotai · Daishi Kato's blog
jotai-tanstack-query
#状態管理 #Redux #Redux_Toolkit #Zustand #Jotai #技術の審美眼
kintone アプリ作成フォームの UI の状態管理のライブラリ選定
@t6adev: 初めてLive Codingをしてみました。
#Signal #Jotai #Daishi_Kato
@dai_shi: Just published Why You Don't Need Signals in React. Because we have Jotai.
https://t.co/2IXL3McPaK
#フロントエンド人物図鑑
https://twitter.com/dai_shi
https://github.com/pmndrs でZustandとかJotaiとかValtioとか作ってる人
よくReactのRFCに登場してくるイメージ
#Jotai
JotaiとOpticsのintegration
https://jotai.org/docs/integrations/optics
#Recoil #Jotai #Atomic_State_Management #アンラーニング
宣言的UIのデータアーキテクチャはコンポーネントを中心に考える
Reduxのようなトップダウン型の状態管理とは考え方そのものが異なる
ボトムアップ型の状態管理をする場合は従来の考え方を一度忘れるといい
→考え方の詳細はAtomic State Managementにまとめた
#設計 #CQS #宣言的UIの設計レシピ #状態管理(GUI)
CQSやってるとコンポーネントとSelector(≒Query)はだいたい1:1になる
その場合、Selectorの定義を分散させたくない
コロケーション、データとロジックは近い位置にまとめるの思想
子のユースケースと密結合なのでSelectorとコンポーネントは同居させたい
#TanStack_Query
Jotaiであれば公式でintegrationが用意されている
jotai-tanstack-query
Recoilなら
Concurrent, Suspenseの文脈でキャッシュ管理と理想的なデータフェッチを考える (Recoil, Aspida, React Query, GraphQL)
#Jotai
https://jotai.org/docs/integrations/molecules
@koushisa: jotai molecules、コンポーネントツリーと宣言的UIのモデルが一致するのでこれまで追い求めてきたものかもしれない
#Recoil #Jotai #Redux #React
ReferenceError: Cannot access 'hoge' before initialization
import/exportの循環参照が発生していることを疑う
Redux ToolKitのドキュメントでも言及されている
#GUI #設計 #Server_State #宣言的UIの設計レシピ
先に結論
MVCはプレゼンテーションのためのアーキテクチャ
関心の分離はドメインとプレゼンテーションから考える(PDS)
データやロジックに関するアーキテクチャではない
#Rx #Signal #BLoCパターン #Observable
from FlutterでBLoCだChangeNotifierと振り回されて消耗するまえに
[10年前にC#がRXをはじめたときからわかっていたはずですが、ObservableStreamは超かっこいいけど使い道の少ない技術です。フレームワークの裏側で使う分には便利ですが、表に出てくるべきではないでしょう。普通のGUIアプリケーションであれば99%のユースケースはただのコールバックで満たせます。 https://hachibeechan.hateblo.jp/entry/change-n
#Rx
from ObservableStreamは超かっこいいけど使い道の少ない技術
正直 Observable 系の型と map と flatMap、filter 以外はいらないと思っている
#(Type|ECMA|Java)Script
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Symbol/asyncIterator
https://github.com/tc39/proposal-iterator-helpers
Rx, モナドっぽいなーと思った
leseqのECMA純正みたいな
#設計 #CQS #状態管理(GUI) #宣言的UIの設計レシピ
from ステート/オブジェクトのライフサイクル
仕組み
リアクティブを知る1歩 - Speaker Deck
Unveiling the Magic: Exploring Reactivity Across Various Frameworks
#設計 #CQS #アーキテクチャ
#WIP #思考実験
大前提:
要求分析
システムの振る舞いを設計する際はコトに着眼する
#設計 #設計原則 #プログラミング
副作用のない関数(Side-Effect-Free Functions)ということ
関数を分割/凝集させる際はデータへの関心でまとめる
以下の特性を持っている
環境に依存しない
#Recoil
https://recoiljs.org/docs/guides/atom-effects/
Rx以外のやり方でリアルタイム通信(WebRTC)とかWebSocketとかStream的な概念を扱える
#プログラミング
FlutterのStreamを使ったリアクティブプログラミングパターン
Rxと似てる
#Recoil #宣言的UIの設計レシピ #状態管理(GUI) #Server_State
Recoilの非同期ステートの抽象クラス
https://recoiljs.org/docs/api-reference/core/Loadable
https://github.com/facebookexperimental/Recoil/blob/main/packages/recoil/adt/Recoil_Loadable.js
#状態管理(GUI) #Rx
https://ngneat.github.io/elf/
RxJS上に構築
#(Type|ECMA|Java)Script
遅延評価コレクションライブラリ
https://github.com/ugaya40/leseq
Lazy evaluation list(lazy list) with high tree-shaking affinity and easy customization.
翻訳
#プログラミング
以下の性質を持つ配列(List/Collection)
最小限の所までしか列挙しない/読まない
無限シーケンスを扱うことが可能
Rx的なもの
#Recoil
https://recoiljs.org/docs/recoil-sync/introduction
Recoilの外部データソースとの連携を抽象化したライブラリ
中身はRecoil > atomEffectsの関数群
ここでの外部データソースはDOMやNavigation Stateなどあらゆるものが含まれる
#パフォーマンス #Redux
from React at 60fps: improving scrolling comments in Figma
We started investigating why the other components were re-rendering when viewport information in the Redux store changed. We found that Redux runs every single middleware and loops through and runs m