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
the big issue of the components is the hacky OO approach: we declare properties in the constructor of the component, use super calls in our lifecycle hooks to make the subscription work build a even bigger component structure which is harder to understand.
The BaseStore utilizes the approach of creating a simple and dumb data object which flushes changes in its state to the view. Stores should be instantiated as they're just simple objects and the instance should be passed to module.exports and not the class. Therefore the BaseStore is not a big design issue, but the BaseComponent is.
The text was updated successfully, but these errors were encountered:
Description of the issue
the
BaseComponent
is a simple hack in the spec of this implementation which shouldn't exist as public API classes should be avoided (https://medium.com/@dan_abramov/how-to-use-classes-and-sleep-at-night-9af8de78ccb4#.jm9evg8ba) and theBaseComponent
is something that should be removed.Instead a lightweight connection library could be created:
What's with the
BaseStore
the big issue of the components is the hacky OO approach: we declare properties in the constructor of the component, use
super
calls in our lifecycle hooks to make the subscription work build a even bigger component structure which is harder to understand.The
BaseStore
utilizes the approach of creating a simple and dumb data object which flushes changes in its state to the view. Stores should be instantiated as they're just simple objects and the instance should be passed tomodule.exports
and not the class. Therefore theBaseStore
is not a big design issue, but theBaseComponent
is.The text was updated successfully, but these errors were encountered: