Proposal to reduce circular dependency headaches

[ronald-mz]

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

import { ObjectModel } from 'objectmodel' 

const Honey = ObjectModel({
   sweetie: undefined // Sweetie is not yet defined
});

const Sweetie = ObjectModel({
   honey: Honey
});

Honey.definition.sweetie = [Sweetie];

Context - Modules example

honey.js

import { ObjectModel } from 'objectmodel' 

const Honey = ObjectModel({
   sweetie: undefined // Sweetie is not yet defined
});

sweetie.js

import { ObjectModel } from 'objectmodel' 
import { Honey } from './honey.js';

export const Sweetie = ObjectModel({
   honey: Honey
});

index.js

import { Honey } from './honey.js'
import { Sweetie } from './sweetie.js'

Honey.definition.sweetie = [Sweetie];

const joe = Honey({ sweetie: undefined }); // ann is not yet defined
const ann = 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.

Proposal - Example

honey.js

import { ObjectModel, RefModel } from 'objectmodel' 

export const Honey = ObjectModel({
  sweetie: RefModel('Sweetie')
}).as('Honey')

sweetie.js

import { ObjectModel, RefModel } from 'objectmodel' 

export const Sweetie = ObjectModel({
  honey: RefModel('Honey')
}).as('Sweetie')

index.js

import { Honey } from './honey.js'
import { Sweetie } from './sweetie.js'

const joe = Honey({ sweetie: undefined }); // ann is not yet defined
// Here is where Sweetie's definition for .honey would finalize.
const ann = 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.
const chelsea = Sweetie({ honey: undefined });
const bob = 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

[sylvainpolletvillard]

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.

[thesunlover]

Hey @sylvainpolletvillard,
Large-scale architectures, including Salesforce, provide multiple examples of circular references, such as Account->Account and Contact->Account, which function reliably. These relationships are managed at the schema or metadata level rather than through runtime module dependencies, avoiding the typical circular dependency problems in code. This shows that circular or bi-directional references can be safe and beneficial when properly designed, even in complex systems. To adjust the Salesforce models into custom JavaScript objects we use ObjectModel, so RefModel would be a natural and useful addition to the existing functionality.