Replies: 4 comments 16 replies
-
|
I finally have some time to work on maxGraph. Good work! |
Beta Was this translation helpful? Give feedback.
-
|
Just pushed my changes into the branch. All the shapes are modified so that there are no longer nullable fields in CellStateStyles. For colors, There might be some broken places by these changes, but I'll fix them once all the compiler errors are resolved. :) |
Beta Was this translation helpful? Give feedback.
-
As I looked more into your code, I finally understood what you meant. I believe splitting Graph.ts into multiple files based on their roles is the way to go, but having nested structure/namespace might complicate things even more :( So, I'm converting Graph* files as mixins to work with Graph.ts. Typescript support for mixins is fairly limited, so I'm implementing a workaround for it. I'll post again when some progress is made. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
I just merged |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all (including but not limited to @junsikshim @coclav @jgadsden)!
Not sure I'll be able to work on this for the next few weeks but have managed to make a reasonable amount of progress - here's a quick status current status in case anyone has any feedback/would like to continue working on it:
I've nearly finished converting all the main stuff to TypeScript, aside from a few files (e.g. the shapes are mostly done, whereas the layout ones I've started but need more type info filled in). The changes are merged to https://github.com/maxGraph/maxGraph/tree/mcyph-graph-refactor
The plan to introduce tree-shaking we discussed I think still remains both the most risky and potentially lucrative part of this. This has involved trying to separate all the
mxGraphclasses into differentGraph*files (e.g.snap/GraphSnap.tsetc) then making all the classes refer to each other via namespaces (e.g.this.graph.snap.(method)), though this is likely a temporary thing until we can come up with a plugin/object-based configurable system or similar.I can vaguely foresee using the graph something like the below mock code, based on charting libraries like Apache eCharts:
The reason why I think providing actual references to the modules in the plugins could be a good idea rather than strings is because explicitly importing would make tree-shaking and parameter checking with TypeScript possible.
This is only preliminary though and would definitely like to know what other alternatives are and their pros/cons before we come to a conclusion!
Beta Was this translation helpful? Give feedback.
All reactions