You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
import{ObjectModel}from'objectmodel'constHoney=ObjectModel({sweetie: undefined// Sweetie is not yet defined});constSweetie=ObjectModel({honey: Honey});Honey.definition.sweetie=[Sweetie];
Context - Modules example
honey.js
import{ObjectModel}from'objectmodel'constHoney=ObjectModel({sweetie: undefined// Sweetie is not yet defined});
import{Honey}from'./honey.js'import{Sweetie}from'./sweetie.js'Honey.definition.sweetie=[Sweetie];constjoe=Honey({sweetie: undefined});// ann is not yet definedconstann=Sweetie({honey: joe});joe.sweetie=ann;
Context - Issues
It is only safe to use Honey's definition in index.js. Importing directly from honey.js could end with an incorrect model definition if index.js is not imported elsewhere.
It hides part of Honey's definition in another file without anything to point a developer towards it. We could add a comment here pointing someone to the definition, but that has some problems too. Like if the file moved.
We could move Honey's definition of sweetie into 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.
import{Honey}from'./honey.js'import{Sweetie}from'./sweetie.js'constjoe=Honey({sweetie: undefined});// ann is not yet defined// Here is where Sweetie's definition for .honey would finalize.constann=Sweetie({honey: joe});// Here is where Honey's's definition for .sweetie would finalize.joe.sweetie=ann;// Definitions were finalized already, so there should be less overhead when creating// instances of Sweetie and Honey for chelsea and bob.constchelsea=Sweetie({honey: undefined});constbob=Honey({sweetie: chelsea});chelsea.honey=bob;
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: