Skip to content

Conversation

@darenkeck-dev
Copy link
Collaborator

@darenkeck-dev darenkeck-dev commented Jul 29, 2025

Description

Server updates to support nested SystemTypes.

  • Adds the parent attribute to SystemType
  • Updates SystemType extraction process to populate the parent field
  • Adds tests for SystemType extraction
  • Update tsconfig target and bump typescript version

Client

  • Add business logic to generate nested structure of templates
  • Update tests for schema updates
  • Update tsconfig target and bump typescript version

NOTE: no visible updates have been made in the client UI. This PR merges work to prepare for displaying nested templates and system type groups.

Related Issue(s)

#455

Testing

Tests have been updated on the server

Copy link
Collaborator

@AntoineGautier AntoineGautier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@darenkeck-dev See my comments:

  • The ES version should be updated if we want to use the at()method.
  • The other one is more a question related to the requirement to organize templates by library.

systemTypeStore.set(systemType.modelicaPath, systemType),
);
// set the systemType reference on the template
this.systemTypes.unshift(systemTypes.at(-1)!);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The at() method was introduced in ES2022, but server/tsconfig.json is targeting ES2019.

Copy link
Collaborator Author

@darenkeck-dev darenkeck-dev Sep 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, good catch. This change should be safe the node version we are using for the parser.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed a commit specifying ES2022 both for the client and server.

const systemType = {
description: type.description,
modelicaPath: type.modelicaPath,
parent: parent?.modelicaPath || "",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to organize templates by library as shown below, don't we need to store the Modelica library as the parent of each top-level system type?

├── Library 1
│   └── Air handlers and fans
│   └── Plants
└── Library 2
    └── Air handlers and fans
    └── Zone equipment

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, this is an important point.

Do you know if we have this information already available, that overall package details get extracted when we go through the template discovery process?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, we don't have this information yet.
I think if we change the following line:
https://github.com/lbl-srg/ctrl-flow-dev/blob/main/server/src/parser/loader.ts#L133
into:

while (packageName) {

we will have the root package details stored as an additional TemplateNode.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the rootPackageName part of the condition and tested both the parser and interpreter and both are behaving well. Also, updated parser tests impacted by this change.

@darenkeck-dev
Copy link
Collaborator Author

@AntoineGautier changes have been made hiding any visible update in the client UI. This is ready for review again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants