Open RonaldZielaznicki opened 1 year ago
All models are meant as wrappers around existing data types in JavaScript, which is not the case for this RefModel.
My opinion is that circular dependencies are a bad pattern and should be avoided. If two models are dependent on each other, they should be part of the same module and be declared in the same scope.
Context
It often happens that an object model needs to reference itself or a model that references it. There exists a work around for this in the FAQ; but I think there are some problems that exist with the work around. Namely while working across file or modules.
Context - FAQ Example
Context - Modules example
honey.js
sweetie.js
index.js
Context - Issues
index.js
. Importing directly fromhoney.js
could end with an incorrect model definition if index.js is not imported elsewhere.honey.js
, but then we have to deal with a circular import.Proposal
Introduce a RefModel that allows you to reference a Model indirectly.
RefModels would resolve to their proper definition later when a model is turned into an instance. Ideally, this would happen once and work as a regular definition from then on.
Proposal - Example
honey.js
sweetie.js
index.js
Other thoughts
using
.as
I'm not married to the idea of utilizing
.as
with reference models. It seemed the easier path, but I could see problems coming in for it's original use case; which is to name the model for debugging. For instance, name collisions if two models are declared with the same string passed to.as
.Could add a new method, to get the job done. Maybe
.ref
? It could throw an error on a name collision.Allowing RefModels to be undefined
In the proposal example, joe is instantiated with sweetie as undefined. As is, that might end in an error unless RefModels also allow themselves to be undefined.
The work to implement the change
Additionally, I'd be willing to implement the changes myself and submit a PR if you're into the idea. Might need a little direction, but otherwise am willing