ダイアログをAction内で呼ぶことを明示的に許容するドキュメントを追加

[Hiroshiba]

内容

利便性を考慮して、ダイアログをAction内で呼ぶことを明示的に許容することにしてみました。
議論あればコメント頂けると！

[yamachu]

確かにモーダル周りの処理は煩雑になってしまうのは理解しているので良さそうに思います。
実際のコードがないためなんとも言えませんが、例えばモーダルに求めている戻り値などをいい感じに抽象化し、action経由で行うみたいな形にすればこの方針でも問題ないかと思います。（例えばPositive/Negativeの値の2値で十分であればそうだし、いや、両方選ばれずCloseされたやつも必要なんだとかであればそれに応じたModalの返り値や必要なパラメータを渡すみたいな）

Viewのライブラリだったりに依存した型だったりを取り除くことが出来れば問題はないと思います。

[PickledChair]

利便性を考慮して、ダイアログをAction内で呼ぶことを明示的に許容することにしてみました。

理想的ではないと思いますが、利便性は確かに向上しそうです。設計の綺麗さより利便性の方が上回ると考えたので可とした、とすると納得はしやすいと思います。

この方針を採用した場合に、他にドキュメントに明記した方が良いかもしれないことを考えてみました（ #559 の例を念頭においています）。必要なさそうであればなくても良いと思います……。

• Dialog を呼ぶ action と普通の action は見分けがついた方が良い？
  • 例外的に認める形になると思うので、そのような扱いであることに後で気づけるようにしたほうが良いかもしれない
  • action 名に _WITH_DIALOG という suffix をつけるなど
• action 内で、Dialog を呼ぶ以外の作業をしている部分は、そこを別の action に分離することを検討するべき？
  • 例えば 音声保存系action実行後にdialogを出すものをstoreに移動 #559 では GENERATE_AND_SAVE_AUDIO_WITH_DIALOG で実際にオーディオ生成する部分は GENERATE_AND_SAVE_AUDIO に投げている
  • Dialog を呼ばない経路での再利用、あるいは複数の経路での再利用が考えられる場合は積極的に分離した方がいいかも？
  • 再利用がなさそうで、かつその作業があまり大きくない場合は分離しなくてもいいかもしれない

あと、 @yamachu さんがおっしゃるように

例えばモーダルに求めている戻り値などをいい感じに抽象化し、action経由で行うみたいな形にすればこの方針でも問題ないかと思います。
...中略...
Viewのライブラリだったりに依存した型だったりを取り除くことが出来れば問題はないと思います。

ということが実現できればより良いと思います。

[Hiroshiba]

Dialog を呼ぶ action と普通の action は見分けがついた方が良い？
action 内で、Dialog を呼ぶ以外の作業をしている部分は、そこを別の action に分離することを検討するべき？

どちらも、これからDialogを呼ぶactionが増えてきてからルール作りしても良いのかもと感じました。
実際どういうケースが必要になってくるかちょっと予想がつかないので。。
仰ることは今のところ確かにという印象だったので、今後レビューでちょっと意識しても良いかもと思いました。

[Hiroshiba]

とりあえずいろんな方に知ってもらえたと思うので、一旦マージします！
将来的に action 内で、Dialog を呼ぶ以外の作業をしている部分は、そこを別の action に分離することを検討する ができると嬉しいかな、という感じです。