技術的に誤った認識でnot for meされるのは悲しいし寂しいので、誤った認識に反論しておきます。
何を以ってオブジェクト指向とするかは人それぞれだけど、Angularはオブジェクト指向ではないと個人的には思ってる。 クラス使ってたらオブジェクト指向、というのであればそれは否定できない。 ちなみに過激というかアドバンスドな設計をすればするほどAngularもRxJSをベースにしたリアクティブプログラミングに寄っていく傾向にある。 AngularとAngularFire（FirebaseのAngular向けライブラリ）を使って簡単なアプリケーションでも書いてみれば多少体感できると思う。
Angularでコンポーネントのクラスが何か継承するケースまず発生しないし、発生してるんだとしたらそれは設計間違えましたね…と手を合わせる感じですね。 ドキュメンテーションのガイドのなかではまず皆無、国内外のブログでもAngularでコンポーネントでextendsしてるものはまず観測しません。 そういったコンポーネントの責務ではない関心事を切り出すためにサービスというものがあるんです。
コンポーネント設計にベストプラクティスが見つからないのは、それはそう。アウトプット追いついてなくてごめんな、って感じ。 状態管理についてはAngularかどうかとかあんまり関係ないし、現状ngrx/storeがメジャーだし中身はただのReduxだから特に欲求がないならngrx/storeで良いと思う。 明確に欲求があるなら好きなもの使えばいい。ObservableでラップしてしまえばなんでもAsyncパイプで購読できる。
マジでAngularがUIコンポーネントに継承使ってるってどこの誰が言いふらしてるのか気になるんだけど。 RxJSについてはコアのビューレンダラー部分からはあまり露出してなくて、バリバリに露出しているのはRouterとHTTPのところでコアからは分離されてるから、そこはそれほど怖くないかなと。 ところで一回触ってみるなら僕がマンツーマンでナビゲートしますよ。
それはそう。AngularはそもそもOOP意識してるわけじゃないし、クラスだからって反射的にOOPっぽく実装すると失敗する、というだけ。 AngularのクラスはClass Decoratorのためのフックポイント以上の意味はない。
そうなんですよ。誰が継承してるって言いふらしてるの
AngularのRouterはCode Splittingが根底にあってバンドル分割のエントリポイントになるNgModuleと切り離すことはできないから、そこは諦めてください
関数型になることは難しい。 ところで関数型プログラミングとリアクティブプログラミングって混同されがちな気がする。 関数型プログラミングをすればたいていリアクティブになるからだいたい重なるんだけど。 コンポーネントのクラスフィールドに状態を持ち、変更検知のDirty Checkでテンプレートに反映される、というのは初心者向けの設計。 中級者以上になってくれば関心の分離のため、コンポーネントから状態を切り出し、サービスから状態の変更が通知されて再描画するという構造に自然と行き着く。 その実装がReduxなのかFluxなのかなんなのかは自由だけど、順当にAngularに慣れていけば自然とObservableをベースにしたリアクティブプログラミングにシフトしていく。
僕も同意です。 みんな継承に恨みがあるのはわかるけどクラス見ただけでOOPだって指差すのは短絡的だと思う。
そんな実装するのはチュートリアルかサンプルアプリケーションくらいだと思います。
そうそう、標準パッケージのAPIに合うようにAngularらしく書いていけばこういうことになります。 コンポーネントが関数じゃないから関数型プログラミングにはなりきれないけど、だからといってOOPというわけでもない。
そう
あまりにも抽象的過ぎて何が何だか分からない 「疎結合、協調性、汎用性、利便性」ってどういうことだろうか
すみませんでした…