Storybook の問題洗い出し

[mizchi]

まず既存の storybook の何が問題かネタ出し

[mizchi]

• webpack v3 依存が激しい。バージョンアップが遅い。中の人達のプログラミング力が信用できない
• story が書きづらい。 module 剥き出しなどAPIが良くない。
• 後付の react 以外の環境のサポートが酷い

[hiroppy]

↑ 同意
できれば、zero configで動くようにしてほしいな。。。(.storybook書くのが大変なのと、tsサポートが弱い)

[mizchi]

@hiroppy
昔 flow の型から props の自動生成を実験してたことがあります
https://github.com/mizchi/flowed-story

[sawa-zen]

やっぱり.storiesのメンテがプロジェクト初期だけになって後々放置されるのでできれば自動生成したいですねぇ。cliのプロパティでstoriesを作成したいディレクトリのパス指定するとかだと使いやすいかも。

[lacolaco]

実装 <=> Story記述 <=> Story のステップが長い。
めっちゃIMHOなんだけど、ほしい体験は

• コンポーネントを選ぶ
• props/attrsを渡しながらレンダリング結果をプレビューする
• ストーリーとして残したい設定を保存する

GraphQLのInsominiaみたいな体験をやりたい。GraphQLのクエリいろいろ試して気に入ったのを名前つけて保存しとく感じ。ストーリーってprops/attrsのプリセットリストだよね、ってみたいな感覚。

[kazupon]

以前 Vue 対応したときの経験からすると、実装部分についてはほぼ同意。ほとんどプロジェクトパッケージコピペベースでやっているので、依存関係とかメンテとかあんまし考えられていないです。

後、プロジェクト自体開発体制も、

• PRしたときの何かやたらとサービスのフックが多い
• 依存モジュールの自動アップデートbotがスパム的

という感じで体制に疑問を持っています。

中身、機能に関しては

• Storyも結局 JS で実装しないといけないので、結局他者が使えるツールとしての手離れ感がない(フロントエンドエンジニアがstory書く。。。)
• アドオンAPIが壊れやすい

自分としてはその辺なんとかしたいです。

[ts020]

ReactNativeで社内エンジニア向けUIパッケージを作ってる中で出て来た課題として

• ReactNativeでStory選択UIが使い勝手悪い。
• ReactNativeだとInfoAddonが動かないので面倒。
• ReactNtiveでのUIの操作性が悪い

[euxn23]

SPA じゃないケース(自分の場合は Rails )での問題ですが、

• Component の fetch で自身のドメインにリソースを取りに行く都合上、storybook で立てると storybook 自身に取得先が向いてしまう

ため、非 SPA (Rails/Laravel)で導入しにくいケースがあるように感じました。

解決策としては既存の Rails アプリケーションと storybook 両方にいい感じに proxy するサーバを立ててそこ経由で見に行くという感じにしましたが、デフォルトでやってほしい

[mizchi]

@euxn23 外部API叩くようなコンポーネントって、それって既にstorybookで扱うものじゃないと思うんですよね…
とはいえ storybook 側にモックサーバーを実装してほしいというのはわかります

[mizchi]

今の所 @lacolaco の案がとてもいいと思っていて、ついでに編集した props/attrs を外部ファイルに書き出しておけば、プレビューの他にもスナップショットテストや最低限 render が落ちないかどうかのテストができるんじゃないかという気がする。

[lacolaco]

Storybookのユースケースって2面あると思ってて、Atomic Design的なコンポーネントカタログをデザイナーと共有するためのリビングドキュメンテーションとしてのStorybook用法と、
リアルタイムにコンポーネントのレンダリング結果を確認しながら実装を行う開発環境としてのStorybook用法。
このコンテキストのギャップは混在するとデザイナーとデベロッパーがどちらも不満足なものになると思う。
僕が言ったようなものは、 たぶん現状のStorybookでstoryをコードとして書いているレイヤーを抽象化してGUIに持ち込む、いわば Story Editor のような概念になりそうかな

[narirou]

現場で幾つかのパターンで利用していますが、@lacolacoさんのような課題がまさにあります。
Storybookを利用した開発で得られるメリットは以下のような点で、

• デザイン面: コンポーネントカタログ(リビングデザインガイド)としての用途
• 仕様面: ドキュメンテーションとしての用途(迷子にならないよう仕様をコンポーネントに紐づけて管理しておく)
• 技術面：UI動作担保 (SnapshotTesting, ImageRegressionTesting)

現状、上記のような用法をどれもデフォルトでは取り込みきれない(できなくはないが、表示の仕方がカタログになりきれていなかったり(デザイナーから不満)、管理していくには実装が大変すぎる(エンジニアから不満)、仕様を整理しようにもシステム的すぎて困難(企画側から不満))状態であるように思います。

エンジニアの動作確認用途に特化するのはもったいなさすぎるので、どの役割の人でも担当部分を参照できるようなGUIがあっても良いなと思っています。

---

あとはプラグイン周りがReactに寄りすぎている現状もなんとかしたいですね。
Viewのパーサーを一段抽象化した層があるといいでしょうか。

[cubdesign]

Storybook使ったことないのですが、もっとデザイナーよりのツールになったらいいと思います。

一見、デザイナーから見ると、Bootstrapのような感じがして実際どんな表現できるのか把握しづらいので…、
本来は、デザイナーとエンジニアのコミュニケーションツールとしてありたいのに、デザイナーがとっつきづらい。

理想的には、色んなフレームワークが共存できるのがほしい。デザイナーからすると、jQueyもReactも同じ、色々混ぜて使いたい

昔、デザイナーは、HTML、JS、CSSを触ることなくdreamweaverでパーツをドロップしてプロパティをいじるったりしてwebページを作っていた。

いまは、adobe xd、adobe museのようなツールを使えば、なんとなく作れるんだけど、リアルな世界では使えない。出力されたソースは、一年後大丈夫だろうか？って思う

React とかのコンポーネントは、そういうのにすごく向いていると思うんだけど、そういうツールのデファクトスタンダードがない。もっと気軽にデザインしたい。

[cubdesign]

ワイヤーフレームから細部のデザインを落としこんでいく、デザインのフローと、細部から作りって、その組み合わせでページを、完成させていくエンジニアのフローに、根本的なギャップがあると思う。

デザイナーからすると、ワイヤーフレームにコンポーネントを配置して、そのコンポーネントのデザインを調整。

それをループして、デザインしていく。

[cubdesign]

部品は、それ単独で使えるときは少なくて、
画面の中で、部品のデザインを変えていく必要があって。

画面を基準に、部品をデザインしていきたい。

エンジニアは、スタイルを部品の中に閉じ込めたくなるけど、デザイナーは、その部品のスタイルを外部からコントロールしたい。

[cubdesign]

スタイルもFluxのフローのように、上からステートで受け渡したいのだと思う。

[cubdesign]

とても、難しいのですが、
この部品を触ったら、ここも変わってしまった。変更したいのは、このページのこの部品なのに。

デザイナーは、そういうのが怖い。

下手に触ってコンポーネントを壊して、エンジニアに怒られたくないので、さわらず、使わずになってしまう。

でも、コンポーネントのバグは、一括で治してほしい。

そしてgitは苦手。

[mizchi]

エンジニアは、スタイルを部品の中に閉じ込めたくなるけど、デザイナーは、その部品のスタイルを外部からコントロールしたい。

これは感覚的にわかって、自分の書く React でも

<Layout>
  <Header>
    <Padding>
      <HeaderContent/>
    </Padding>
  </Header>
</Layout>

みたいな間に挟んで余白調整するだけのコンポーネント出現しがちで、その分類が難しい問題があると思ってます。

[AKIRA-MIYAKE]

エンジニアは、スタイルを部品の中に閉じ込めたくなるけど、デザイナーは、その部品のスタイルを外部からコントロールしたい。

自分は、コンポーネントのスタイルはそのコンポーネント自身についてのみ記述して、余白調整等はmarginやpaddingのみをもつ mx2 のようなユーティリティクラスを受け取って行うようにしています。

[ln-north]

些細かもですが StorybookのUIでknobsの選択が大きなコンポーネント(Atomic DesignのTemplateあたり)になるとめちゃくちゃ多くて探すの大変なので階層化したいです

[trkw]

NuxtとStorybookを利用していてでてきたこととして、
Vue Forumのトピックでk-okinaさんも書かれている、共通のwebpack.config.jsを利用したいという課題を共有させてください。

Vue Forum URL
Nuxtのwebpack configをstorybookで使いたいです - 日本語 - Vue Forum

実際のコードは以下JavaScriptファイルのように、nuxt.config.js をStorybookの webpack.config.js で require して共通で利用できるコードは利用して、sass-resouces-loaderはStorybookに設定し直す形になってしまうため、Nuxtのnuxt.config.jsとStorybookのwebpack.config.jsを修正する必要があるコードになってしまいがちかなと思います。

GitHub URL
https://github.com/soussune/soussune.com/blob/master/config/storybook/webpack.config.js

sass-resouces-loaderについては、Qiitaにも記事にされている方がいらっしゃったので参考URLとして載せさせていただきます。

Qiita URL
Nuxt.js + Storybookでsass-resouces-loaderを使う

必要なconfigファイルを書くだけじゃないかと言われたらそれまでなのですが、なんとかしたいなぁーと思います。

[kazupon]

Storyも結局 JS で実装しないといけないので、結局他者が使えるツールとしての手離れ感がない(フロントエンドエンジニアがstory書く。。。)

GraphQLのInsominiaみたいな体験をやりたい。GraphQLのクエリいろいろ試して気に入ったのを名前つけて保存しとく感じ。ストーリーってprops/attrsのプリセットリストだよね、ってみたいな感覚。

@lacolaco さんのコメントも元に、自分がコメントした手離れ感がどんなものかをさらに補足すると、

最近、metabase を仕事で使っているんだけど、metabaseでは、まさに、GraphQLのInsominiaに近い、queryをquestionっていう概念モデルがあります。このquestionというやつ、以下のgif動画
とスクリーンショットのように、ポチポチという感じでGUIで簡単にDBのqueryを構築できるようになっていて、さらに表示する際のビジュアルの形式(テーブル、折れ線グラグなど)を名前つけて保存できるようになっているスグレモノ。SQLにも変換してそれを元にカスマイズできる。

そんでもって、この作った questionを元に、ダッシュボードを以下のgif動画みたいに作れてしまう。

next-age-stories もこんな感じにできたならなと思っています。

これを next-age-stories の世界にすると、storyは metabaseのquestion で storybookの knobs アドオンみたいな Story Editor でprops/attrsをいじってstoryとして保存して使い回すという形になるという感じでしょうか。

[kazupon]

エンジニアは、スタイルを部品の中に閉じ込めたくなるけど、デザイナーは、その部品のスタイルを外部からコントロールしたい。

ちなみに、Storybook v4 では variables や configで theme できるようにするっぽいです。:thinking:

storybookjs/storybook#3628