デザインエンジニアしか知らない世界 後編

こんにちは、omoteです!
デザインエンジニアしか知らない世界 後編です。
前編はこちらからどうぞ。

前回に引き続き、Reactコンポーネントの設計について話していきたいと思います。

SuspenseというAPIが出現した件

きょんしーに取り上げてもらいました。
Suspenseは、React16.6から追加され、React18から正式採用された機能です。

「ローディング中はレンダリングできない」という状態をコンポーネントごとに管理できます。
ReactはDOMを生成しUIを表示するためのライブラリです。
つまり、画面中に1つでもローディングできないデータがあれば、レンダリング結果が帰って来ず、DOMの生成がされない=画面に表示されません。

今まではTanstack QueryでisLoadingなどの状態を読み込んで、コンポーネントを出しわけしていました。

isLoadingを使ったパターン
const [users, isLoading] = fetchData('/users')

if (isLoading) {
  return <Spinner />
}

return <Users data={users} />

しかし、ページ全体での表示・非表示が切り替わり、大雑把な出し分けしかできません。
また、画面全体をローディング状態にした時、ユーザーの操作ができないので、体験を損ねる恐れがありますし、全てのデータのダウンロード完了するまで待機するということを強制されます。

「ページ単位でのisLoading, isError 変数からの独立宣言をなんとでもしたい…!」

そこで現れたのが<Suspense>でした。
このAPIを使用することで、コンポーネント自体がローディングの管理をしてくれます。

<Suspense />を使ったパターン
const Parent = () => {
  return (
    <Suspense fallback={<SkeltonLoading />}>
      <Users />
    </Suspense>
  );
};

const Users = () => {
  const users = useQuery({ queryFn: fetchData("/users"), suspense: true });

  return (
    <>
      {users.map((user) => (
        <p key={user.id}>user.name</p>
      ))}
    </>
  );
};

Promise自体を渡すということにはなるものの、コンポーネントごとにローディング中やエラー中の制御ができるようになるので、よりデザインにおいても選択肢は増えるかなと思います。

遅延ローディングで、データ量を節約したいときなどはよさそうです。
スケルトンスクリーンなどのコンポーネントにいいかもしれませんね!

引用:https://medium.com/creditas-tech/react-suspense-swr-skeleton-e1979e9f32f0

言うなれば、個別に制御しやすくなった分、ローディング中のユーザーの退屈時間は消えます。
ローディング中の退屈さから解放される日も近いかもしれませんね!

ビジネスロジックがコンポーネントに内包されないように、外部からfetcher流したらいいかもね!という声も出てきました。

勉強会での声

  • ビジネスロジックがコンポーネントに内包されるかもしれないので、外部からfetcher流したらいいかもね!
  • Promiseを渡すのは不思議だけど、慣れかな?

解答

とはいえデザインパターンはまだまだ未知数です!
estieでは、ここのベストプラクティスについてもまた研究していきたいと思います。

componentの責務分けを仕組みでなんとかしたい件

ReactやVueを使っていると、コンポーネントには大なり小なり依存関係が発生します。
これらはルール化して、ドキュメントに依存関係、ルール関係を記載して多いのではないでしょうか。

そこで、ナレッジワークさんの開発したeslintプラグインである、
eslint-plugin-strict-dependenciesが使えるのではないかと、取り上げてくれました。
Made in Japan!

  • Atomic Designで言えば、AtomsにMoluculesに入れたくないとか。
  • <Button />コンポーネントに、Pagesに入れられないようにするとか。
  • Organismsの中にOrganismsコンポーネントの設置を許容するかどうか。

勉強会での声

  • ルールを言語化する手間が減りそう。
  • 意図しないヒューマンエラーも仕組みで潰せそう。
  • JavaScript・TypeScriptはimportexportが増えがちなので、統制が取れて助かりそう。

解答

あくまでもeslintプラグインなので、導入も難しくなさそうです。
estieのプロダクトでも使っていきたいと思います。

おわりに

古き良きインターネッツを彷彿とさせるようなネタや新しいReactの技術まで、みんなでワイワイしていきました!
estieでは、互いの知識を共有する社内勉強会などの仕組みを、楽しく、積極的に行なっております。

雑談や知見の共有まで、是非お気軽にご連絡ください!

hrmos.co

© 2019- estie, inc.