Defining a Modular Type System
Struggling to create a modular type system that meets my needs in an efficient manner. The core issue revolves around needing two variations of the same type system for frontend and backend purposes. This requirement stems from the necessity to derive one representation from the other.
The model can be comprehended as follows:
- A
Userpossesses multipleTeams. - A
Teamcomprises multipleUnits.
This encapsulates the conceptual essence denoted by (A):
type IUser = {
username: string,
teams: ITeam[],
};
type ITeam = {
teamname: string,
user: IUser ,
units: IUnit[],
}
type IUnit = {
unitname: string,
team: ITeam ,
}
The crucial aspect here is the bidirectional traversal between entities, requiring access both upwards and downwards. From User -> Team to Team -> User, facilitating seamless interaction across all levels.
Contextual Clarification
While the above structure aptly caters to frontend functionality, a different depiction is warranted for backend operations. Leveraging TypeORM necessitates rendering these constructs as Entities, leading to code akin to (B) - stripped off any specific TypeORM nuances.
import {Entity, Column, OneToMany, ManyToOne} from "typeorm";
@Entity()
class User extends BaseEntity {
@Column()
username: string,
// A User has many Teams, loaded lazily
@OneToMany(() => Team, (team) => team.user, {})
teams: Promise<Team[]>,
};
<Entity>()
// More content goes here...
To conform with TypeORM's guidelines, decisions regarding eager versus lazy loading were discerned. Loading sequences descending down the hierarchy occurs lazily, while upward traversing unfolds eagerly.
Merging Models
The objective remains merging model (B) into model (A) with certain fields undergoing promisification. Verification of this amalgamation would validate the structural coherence.
Identified Dilemma
Challenge surfaces in verifying the correlation between models (A) and (B) due to promisified references intersecting various properties within the structures.
Experimentations Undertaken
An interactive TypeScript playground link delves into disentangling this web of conundrums, concentrating solely on dissecting actual definitions devoid of TypeORM intricacies : Playground link
Incorporated are the aforementioned model representations alongside deliberations on derivation strategies. However, grappling with expressing requisite recursion hinders progress, evident through the completion of the playground exploration.