Couple of architectural questions regarding the Concerto Graphical Editor #508
Description
1. Distribution Architecture:
When discussing building the editor as a "standalone widget" that can be embedded into tools like VS Code or the Template Playground, do you have a preferred architecture in mind for its distribution? I notice that Accord Project already distributes several UI tools as React npm packages (for example, @accordproject/ui-markdown-editor and @accordproject/template-engine). Are you envisioning that we distribute the graph editor as a similar standard React npm package, or are you looking for a framework-agnostic Web Component / compiled script so it can be embedded into non-React environments?
2. Standardizing on concerto-core:
For the bi-directional syncing logic, I am relying heavily on @accordproject/concerto-core—specifically using it to parse the .cto text into an AST, load it into the ModelManager, and utilize the Introspector API to extract the declarations into graph nodes. Because text-to-graph and graph-to-text syncing is the core challenge, I wanted to confirm: is concerto-core the singular "source of truth" I should use for all parsing and serialization, and are there any specific built-in utilities I should leverage rather than writing custom serializer logic?