Week 6 - Composition in the frontend
Summary
This week was a transition week, as I finished the refactoring of the components needed for implementing subtree composition in the backend. I also discussed with other contributors to adopt a unified implementation language and quick-started the process of refactoring to TypeScript the whole codebase. My main changes on that front were:
- Diagram Editor: now it is a completely pure component, and it can receive both “main trees” and subtrees.
- Node Header: Enhanced the node header for better clarity and interaction.
- Tree API Calls: Optimized API calls for better performance and reliability.
- Header Menu: Refined the header menu for a cleaner user interface.
- App.js: Standardized in TypeScript to ensure consistency and reduce errors.
After that, I branched off the work done in PR 188 to integrate all the refactoring into the composition. In order to do that, I had to do a heavy rebasing process.
Subtree composition with depth 1
Subtrees are syntactically identical to the main tree of the application, they just require different processing both in the backend and in the frontend.
Expanding from the work done in the previous week, I finished a first basic implementation of subtree support, just with depth 1. This means the subtrees cannot contain other subtrees yet.
Support in the backend
This involved creating new folders in each project to store the subtrees, and the API endpoints to manage creation and saving. These endpoints have a very similar structure to the ones used for managing the main tree, they receive a JSON from the graph editor, translate it to XML substituting the necessary actions and then stores them in the appropriate folder.
I also change the generate_app endpoint, specifically the functionality for creating self-contained trees, so it supports subtrees.
This piece of code is responsible for taking the main tree and the actions code and create a self-contained XML that can used at runtime by the TreeGardener’s factory. As previously mentioned, I thought about the possibility of adding the subtree support precisely here, but I discarded the idea in favor of doing it at app creating time.
In order to do this, the XML tags representing subtrees have to be substituted with their specific implementation. In order to do this, the tree generator has to check which tags represent subtrees (it is done similarly as with the actions), parse their implementation and properly add them to the main tree. While doing that, it also has to take into account the actions that may be used in the subtree.
Support in the frontend
Now that the tree editor is a pure REACT component, it can edit any JSON it receives. Using the new endpoints, the JSON of the subtrees can easily be retrieved and save.
For that reason, my work focused of properly managing the state, so the user could click from the main tree on a subtree component and this subtree properly opens. This first implementation works with modals, opening a new editor inside it.
I also added the necessary UI components, as a subtree creation button.