React-diagrams: How can I learn more about architecture of the project?

[sg1705]

I'd love to learn more about the internals and architecture of react diagrams, and I'd love to contribute to documentation. But I am not sure how where to start. @dylanvorster any tips?

[kbruskiewicz]

As some hints:

• It's not a typical React project in that it predominantly maintains its own state and event handling. This might make it difficult to relate to a React codebase if your primary background is just in React (although it can be done, see this port: https://github.com/woodenconsulting/react-js-diagrams).
• It's also not a typical React project in that it's primarily an object- and inheritance-driven codebase, rather than using declarative, presentational components as has become the norm since React v16 and the introduction of hooks.

Particularly in v6 it looks like the devs have consistently applied the Factory Pattern across all of their entities. So everything from the diagram itself to its nodes and links has internal state, a widget to render it, and a factory to construct it for pushing into the engine.

This means that every time you want to introduce a customization you should be extending their default Widgets, Models _and_ Factories and then register instances of these Factories to the diagram engine before the component itself gets mounted. Reading the examples demonstrates this.

Likewise their event-handling system looks custom and is probably driven by their work done in https://github.com/projectstorm/react-canvas. It uses a custom event bus that resolves the stream of user actions against the engine's state machine, which probably changes the entities in regular ways (like marking them as selected or deleted).

I haven't found a graph/diagram component written in React that hasn't had to create a thick client to prevent compromising its functionality. So this shift to these idioms is understandable.