関数型コンポーネントについていけない予感がする

Azure Communication Serviceを使うと、Zoomのような通話アプリを独自に作成することができます。そして、React製の UI Library も用意されていて、その中の CallWithChatComposite を使えば、すぐにそのアプリを試してみることができます。このコンポーネントは優れていて、難しいことは全てその中にラップされていて、Communication Service の何を知らなくてもアプリを作成して使用することができます。複雑な仕組みは隠ぺいされていて利用者に必要なインタフェースだけが見えている。理想的なコンポーネントのお手本と言えるでしょう。

さて、そのコンポーネントの表示にカスタム要件が生まれました。

• コントロールバーを分離して、ヘッダーへ移動してほしい
• 自分のビデオ表示窓が小さい→他ビデオ窓と同じ大きさで表示してほしい

はい！ですよね、こうゆうカスタマイズ要件はふつうに起こるでしょう。しかし、今回は方法がわかりません。調べていくうちにどうもその手段がないということがわかってきました。うみゅう、いったいどうゆうことなのでしょう？

いろんなパーツで構成されるこのような複雑な複合コンポーネントはこれまでもよく使ってきました。GridやChartやReportなどのようなコンポーネントです。でもってこれらのコンポーネントはプロパティを介してその内部部品にもアクセスできるようにデザインされているのが普通でした。そう、Objectとしてその操作の予想がつくのです。CallWithChatCompositeについてはその期待は裏切られます。しかしそれはObjectではないので、そうなるのも当然のような気がします。もし、CallWithChatCompositeを自分で組み上げているのなら、そうなるように作成すべきなのでしょう。関数型のシンプルさの徹底が現れていると思います。しかしそれは一介のコンポーネントユーザーには少し冷たい気がします。もし時間があれば、TelerikやInfragisticsさんなどコンポーネントベンダーさんのGirdコンポーネントのfor Reactとfor Blazorを比べてみようと思います。

正直いうと、useStateやuseEffectにも恐れを抱いています。ぶっちゃけこれを、これを素直に理解、納得することができません。Reduxが複雑すぎる！と感じたときに似ています。おそらくこれに慣れることはない気がします。育った環境が違うのでNativeになることはできないのでしょう。

あと、これはReact関係ないですが、node_modulesデカすぎ！も、ちょっと嫌。無駄にデカすぎる気がします。さよなら。