Zenn
Open5

気になったTech系記事/イベントをまとめていくScrap

ピン留めされたアイテム
wtkmnwtkmn

Hrajuku.ts Recoil勉強会

イベント概要

https://babel-jp.connpass.com/event/263696/

※ ailead では recoilも部分的に用いられている

Uhyoさん

要約

  • Fluxは天才だった
  • Recoilならやり直せる

内容

UIを構築する以外の仕事はReactにはやらせたくない

コアな状態は少なければ少ないほどよい

描画以外の部分をRecoilにやってほしい

Recoil
atom: 自身で樹応対を保持する
selector: 他の状態を見て計算する

非同期ネイティブ

ロジック用のReactのような使い心地

  • イミュータブル・冪等性が前提のAPI
  • 計算結果の一貫性の保証

atom と selector の使い分け

他に従属しない状態がatom それ以外は何が何でもselecotor

検索画面
検索条件：atom
ページ数：atom -> Userが独立して変更できる
検索結果：selector -> 上記2つから計算できる
ページネーションがカーソルだと迷う？

使い方は基本的にhookベース

データフローグラフ
atomから始めるデータの流れがRecoilのAPIを用いて定義される

Recoil層からの入力は基本的にコア状態の変更として作用させる
入力用フックを介して、コア状態を更新する。
ユースケースに応じた個別の入力用フックがある

Recoilを使う場合は、React層にはいる前に計算が終わっている
よさ

Reactにロジックを載せると、整合性を保つのが難しくなる

整合性保証

Reactの整合性保証：状態→画面の整合性
Recoilの整合性保証：グラフ→状態の整合性

Recoilを活用するデータフロー設計
シンプルローレベルなAPIから構成されているとkろ
Reactより無理が聞かないので、望ましい設計を保ちやすい

Yoshikoさん

https://zenn.dev/yoshiko/articles/607ec0c9b0408d

SPAにおける3種類のStateの分類

状態

  • Global State : Componentを超えて / LifeCycleを超えて共有する必要のある状態
    • Server Data Cache : サーバーデータのキャッシュ
    • Global State' : 上記以外
  • Local State : Componentに閉じた状態

それぞれに適したLib

ServerDataCache -> SWR, ReactQuery
GlobalState -> Recoil
LocalState -> React

使い方

ピュアなGlobalStateとしての使い方
APIも9割程はatom

  1. 置き場所・命名のルール
  • src/globalStates 以下に置く。1Stateあたり1ファイル
  • ファイル名がRecoilのKeyになっている
  1. 露出させるインターフェイスのルール
  • RecoilのAPIを直接露出させず、Read用, write用のカスタムフックのみを露出させる
    • ライブラリの知識を隠蔽できる
    • Write操作に意味を付けられる
      • state更新の意味合いをstate側から提供し、使い方を限定できる

※腐敗防止層は、主要なライブラリについては、全て入れている

  1. Readhook
  • 大体useRecoilValueをラップしているだけ
  1. WriteHook
  • 関数のまとまりをExportしている
  • 動作に専用の関数を入れている
  • 関数は必ずメモ化する（使う側でdepsに入れることを想定している）
  • 任意のusecaseから呼び出し可能
  1. callback ルール
  • useRecoilCallback
  • atomへのsubscribeは発生させたくないけど、atomの値だけを取得したい場合

おやくそく

ナレッジワークス、採用しているよ

Okunoさん

https://speakerdeck.com/okunokentaro/harajuku-dot-ts-meetup-recoil

状態は管理したくない。

状態とは

  • ユーザーのログインの状態
  • フォームの入力値
  • GUIの表示状態

状態の管理はどこ？

  • LocalStorage, SessionStorage
  • URLSearchParams
  • IndexedDB
  • 状態管理API, ライブラリ
  • useState(), useRef()

状態の多さ - アプリケーションの複雑さ
状態の多いアプリケーションは複雑である
状態の多さは表示要素の多さではない
DBにて永続されたものであれば、状態は複雑地鳴り内

状態管理 = キャッシュではない

  • fetchしたばかりのデータを状態管理に入れない

SWRを使おうよ

思考停止でオレオレキャッシュを実装しない

状態管理とキャッシュ戦略は異なる概念

キャッシュ：表示の高速化、リクエストの削減によるコスト削減
状態管理：永続化されない状態の管理

仕組みづくりはオンボーディングコストから

チームメンバーの出入りが起こるのだれば、オンボーディングコストをむやみに上げるのは得策ではない
チーム加入直後から高生産性を発揮させられるか
前任者の離脱以降もメンテナンスを維持できる？

キャッシュ以前にfetchをへらす

  • fetchした値はそのままコンポーネントの必要箇所にバインディングして描画すれば十分
  • コンポーネント再描画で発生する通信はブラウザを信じてガンガン実行
  • そもそもReact自体をよく学習し、冗長なコンポーネント再描画をへらす努力をする
    • MSW

Recoilはいつ使うのか？

  • gui は useStateで十分
  • react-hook-form
  • 複数のページをまたいで使用する状態はURLSearchParamsを検討する
    • エンドユーザーによってブックマークされうるページか
    • LINEのようなメッセージアプリで共有されるか？
    • ブラウザの戻る機能を併用された時、どうするか？

じゃあいつRecoilを使う時

  • Propsバケツリレーがあまりにも頻繁で生産性・可読性とも低下を実感する時
  • 全ページで必ず利用する情報があるとき

contextの代用品としての利用法

RecoilSelectorはつかわない

  • contextの代用品という立ち位置なので、Contextの代用以外のことはしない
  • RecoilSelecorの使い方のルール周知が難しい
  • Reactの一般スキルさえあれば、開発できるような状態を作っている

useRecoilStateの扱い方
コンポーネント無いでいきなりうせRecoilStateを呼ばないようにしている
理由

  • useRecoilStateのを扱う処理のテストをコンポーネントなしに実施するため

@packageっていうUhyoさん作成のライブラリがとても便利

@na2hiroさん

Recoilと将棋ったー

100種類以上の変速将棋を実施できる
TechStack

  • Remix
  • React
  • Recoil
    その前は、PHP, 生JSだった！

構成
React Router. Remix

  • ページ遷移 / URLから派生する状態
  • URL
  • writeリクエストのハンドリング

Recoil

  • 将棋板

盤の表示
棋譜をatomに定義
board

コマの可動域の表示→掴んだコマの座標をatomを定義
可動域はselector

掴んだコマを話すには
同じところをクリックし直すと、コマを話したい
愚直にやるなら、座標クリック時に、同じ座標を選択済みかどうかを確認

コアなatomを一つ用意して、それに対するラッパとしてselectorを用意する
hook の形でlogicをカプセル化することもでｋる

棋譜の再生
手数→atom

「RecoilRootごとに異なる状態をもたせられる」という発想

QA

Q：selectorの中でfetchできるが、やるか？でテストはどうするのか？

uhyoさん
cacheをrecoilに頼るのが正しいのか？という概念がある
selector単位でUnitテストする

fetchのmockはgqlのレイヤでmockを挟んでいる。gqlクライアントがモックしてくれる

na2hiroさん
Remixに全て任せている
httpRequestを使っている
Shogitterでは一切Unitテストを書いていない。CypressでE2Eしている

fetchのmockをどうするか次第

Q：サーバーからデータを取得する部分をどうするのか？取得したときのデータを編集したときどうするのか？
uhyoさん
Userが編集する場合、それはatomにしないといけない。
依存先の値が変わったときにresetされるatom
依存先のselectorの値が変われば、自分自身の値が書き換わるatomを用意することができる

Q：Recoilでテストを用意するとき、結果の検証時はRecoilそのものの値をみるのか、Component側をみるのか
Recoilの状態を直に見に行くとホワイトテスト的になるが、そこはどうなのか？

okunoさん
テストでは、RTLとmswを使っている。

runRenderHooks?みたいな関数を自分で作っている。
RecoilRootをRTLの中で呼ぶようにしている。
結合テストっぽく、外部から見ている

jestのtestで、recoilのstateを抜き出している。

Q：Recoilが辛くなる性質のアプリ、使わない理由があれば

uhyoさん
UI層で扱うべきStateがあれば、それはRecoil使わない
Recoilはロジックを書くものと想像している

okunoさん
Recoilがすたれたらどうしますか？→周りが使わなくなったら、、

wtkmnwtkmn

2022/12/08

デザインシステム構築の第一歩 〜takanoripさんとSakitoさんに学ぶ

https://findy.connpass.com/event/267065/

まとめ

  • デザインの必要性を価値の部分まで落とし込んで説得できている
  • デザインチームのサイクルを開発サイクルと揃えている
メモ

始め方

Ubie
デザインの再現性のコンポーネント化から初めて、それをまとめたものをデザインシステムとした
デザインシステムを最初から目的にしていたわけではない

Cybozu
手段としてのデザインシステム
1ヶ月くらいでみんなで勉強して、みんなの目線を揃える
6人くらいのチーム
ボタンから 1コンポーネントから

会社の中での位置づけ

Cybozu
チーム立ち上げの時期な期限とかは特に無い
必要であることを十分に説明

Ubie
特にマネージャーはいない
やるかどうかの判断は
技術投資に対するハードルは高い
事業成長に直接的につながらない技術投資にたいしては、慎重になりがち

チーム構成

Ubie
デザイナー＋デザインシステムで構成
全員兼業メンバー
デザインエンジニアは、デザイン＋実装までやる

Cybozu
マネージャーは居ない
DesignTechnologistが主体のチーム
兼任のメンバーもいるが、ほぼ主務
デザインシステム以外もやっている
デザインから実装まで。プロトタイプ作ってプロダクトに入れるところまで

デザインシステムの認知

Ubie
デザインシステムのReturn

  • 作業効率Upで節約される時間
  • デザインの一貫性がプロダクトのメトリクスに与える影響
    ビズサイドへの共有
    デザインComponentの置き換えが大変だった。
    置き換えの最中にも新しいComponentが発生したりする。

Cybozu
ボタン単位から初めて少しずつコンポーネントを置き換える
置き換えは自分たちでやってしまう
PRをだす、QAの人もチームがいるので、プロダクトチームからするとマージするだけ
コンポーネントが入っていくと、デザインシステムに依存するようになる。

＜移動の関係で、以降は聞けず、、、＞

質問

  • デザインによる価値向上はどのように計測される？
  • OKRへの落とし込み方
  • 経営メンバーとの共有？
    • Ubieでは一応報告はしていて把握しているはずだが、承認を得る必要はない
    • デザインチームもなくそのオーナーもいない。
    • サークル「デザ価値」サークルのリードが決める
  • デザインシステムやっていく胆力
    • マネージャーが居ないから楽ということはない
    • むしろ自分たちでやっていく必要がある
  • デザインシステムの浸透

https://speakerdeck.com/takanorip/dezainsisutemuyun-yong-tookrfalseliang-iguan-xi?slide=20