Very cool project ! I've myself written some playground code to wrap mini-mongo documents in immutableJS structures to allow fast shouldComponentUpdate() checks in "pure" react components - I was actually a bit surprised that there didn't exist a Meteor package for this :-), since it can speed up rendering by orders of magnitude.
At the moment, it seems your package creates each document as a "simple" Immutable.Map (created with Immutable.fromJS(fields)). This has the drawback of forcing every consumer down the road to switch to the special "doc.get('field')" syntax, and also doesn't allow adding custom model-logic (helper methods, etc) on your documents.
Using ImmutableJS Records let you use custom classes for each "type of document", and keeps the plain old doc.field syntax for accessing values, so components down the road don't even need to know they're reading from an immutable structure. Coupled with https://github.com/gozala/typed-immutable, it also lets you define "record types" for nested properties - e.g. 'profile' is a Profile Record, 'profile.adress' is an Adress Record.
In short : Records are cool :-)
So it would be nice if the ImmutableObserver.Map() / ImmutableObserver.List() APIs allowed an optional 'documentConstructor" callback, so the caller can specify something like doc => new MyRecord(doc)
Very cool project ! I've myself written some playground code to wrap mini-mongo documents in immutableJS structures to allow fast shouldComponentUpdate() checks in "pure" react components - I was actually a bit surprised that there didn't exist a Meteor package for this :-), since it can speed up rendering by orders of magnitude.
At the moment, it seems your package creates each document as a "simple" Immutable.Map (created with
Immutable.fromJS(fields)
). This has the drawback of forcing every consumer down the road to switch to the special "doc.get('field')" syntax, and also doesn't allow adding custom model-logic (helper methods, etc) on your documents.Using ImmutableJS Records let you use custom classes for each "type of document", and keeps the plain old doc.field syntax for accessing values, so components down the road don't even need to know they're reading from an immutable structure. Coupled with https://github.com/gozala/typed-immutable, it also lets you define "record types" for nested properties - e.g. 'profile' is a Profile Record, 'profile.adress' is an Adress Record.
In short : Records are cool :-)
So it would be nice if the ImmutableObserver.Map() / ImmutableObserver.List() APIs allowed an optional 'documentConstructor" callback, so the caller can specify something like
doc => new MyRecord(doc)