You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off, thanks to the maintainers of this example for everything you've done. You've saved me a lot of time in my AngularJS+ng-redux to Angular+angular-redux/store+TypeScript upgrade!
I'm curious as to the reasoning behind the choice to have the example use this pattern of having Elephant and Lion sort of "inherit" from Animal. It's been my experience that whenever I've tried, in actual client work, to apply inheritance somewhere, the children end up diverging, and I end up regretting it.
So I think the pattern is not a common use case, and more importantly, it creates an obstacle toward the goal of this codebase, that is, to understand how to use angular-redux.
While this abstraction is fascinating, I would really prefer to lose one of the animals and just see an implementation where one of the two has its own components, actions, epics, reducer, service, etc.
If you're open to this, I would absolutely be willing to do the work myself and submit a PR.
The text was updated successfully, but these errors were encountered:
Yeah the two pages are a bit redundant. We could probably stand to lose one. I'm with you about inheritance, although technically this is more akin to genericity instead which has fewer problems: effectively the pattern is more like AnimalList<Lion> and AnimalList<Elephant>, where Lion and Elephant aren't really related to each other, beyond implementing the same basic interface.
First off, thanks to the maintainers of this example for everything you've done. You've saved me a lot of time in my AngularJS+
ng-redux
to Angular+angular-redux/store
+TypeScript upgrade!I'm curious as to the reasoning behind the choice to have the example use this pattern of having
Elephant
andLion
sort of "inherit" fromAnimal
. It's been my experience that whenever I've tried, in actual client work, to apply inheritance somewhere, the children end up diverging, and I end up regretting it.So I think the pattern is not a common use case, and more importantly, it creates an obstacle toward the goal of this codebase, that is, to understand how to use angular-redux.
While this abstraction is fascinating, I would really prefer to lose one of the animals and just see an implementation where one of the two has its own components, actions, epics, reducer, service, etc.
If you're open to this, I would absolutely be willing to do the work myself and submit a PR.
The text was updated successfully, but these errors were encountered: