-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for functions on sub-docs via proxies #502
base: master
Are you sure you want to change the base?
Conversation
…njected via the models .define method during createModel
… is actually required by the schema
As a follow up, seems the automated integration fails due to the absence of Proxy, which indicates that it's running a fairly old node.js without ES6 support. All the tests pass on my local machine. Proxy support is present within Node.js since v0.7.8 but disabled by default behind the --harmony_proxies flag. Perhaps this change would be better suited instead as a downstream repository of thinky unless the idea of a minimum node version is viable. |
On the back of my previous PR, I sought to investigate ways to avoid polluting the documents themselves with additional functions/properties, which has brought me to this branch of using javascript proxy objects instead. Hence, the only altered files are model.js (to add support for the proxy) and schema.js (to support extraction of functions from model definition).
There is one potentially breaking change that this introduces, which is that it causes issues with strict equality checks between an object passed to the document constructor and the document itself. This is because the constructor now returns the proxy object when sub-doc function support is required. I'm not sure how important this is in production use cases, but if the new functionality is not used then there is no breakage as the proxy step is skipped if it isn't needed.
Keen for any feedback. As I said in the other PR, this is functionally addressing the following use case:
Aside from defining virtual properties, there is (AFAIK) no way to define a method or function on a sub-document of a model?
Using my changes, the answer to the above would be:
Defining virtual properties on sub-objects is not currently feasible in all cases since not every function attached to an object produces a value or has output that belongs in a database.