Closed dotansimha closed 8 years ago
Am i right that the last construction is equivalent to (without @MongoCursor):
constructor() {
this.autorun(() => {
this.myData = MyCollection.find().fetch();
});
}
Hence, it makes sense to my mind if autorun
is moved inside. Though, not sure about the name (it's more like @Fetch
), and how big is overhead if the use had to write autorun
and fetch
himself.
Ignore this if I don't know what I'm talking about, but what about a service exposing an array to the component? Get the data stuff out of the component and into a service class with the autorun and subscribe functions. Any update or insert, subscribing and the like is better encapsulated, allowing component reuse for different collections, and moving any of the mongo specific calls into the service. There would need to be an ngclose call for cleanup, and the service could be injected into either the component or bootstrap. I'm not certain if there are lifecycle hooks into injectables for cleanup.
@dotansimha any solution? workaround?
RxJS-compatible verison of Meteor API added https://github.com/Urigo/meteor-rxjs
The current Differ is not enough, it has great advantages, but one big disadvantage - it does not provide access to the Array that ngFor creates, so the access is only available within the view, and it is not possible to get that array in the component's class. It is possible to perform
MyCol.fetch()
but it is not reactive, and the effort of making it reactive is too much, because every user who writes real application will do it, and for each one of his collections in use.Some ideas I had:
async
Pipe (best performance, hard to use from the component’s code, Angular2 best practice)Implemented @Mongo.Cursor decorator for some tryouts:
It works, the actual usage is as follow: