Support for functions on sub-docs via proxies #502
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.