Making a workflow library do what it was not built to do
Adding custom elements and behaviour to a mature open-source workflow modeller, without forking it.
- React
- TypeScript
Outcome
- Custom workflow elements that behave like the built-in ones, including undo and validation
- No fork of the upstream library, so version upgrades stayed routine
The problem
The library is good, with a clear model of a business process, and our customers had processes that did not fit it. We could fork it and maintain the fork forever, work around it and end up with two versions of the same diagram, or extend it the way it was designed to be extended.
Most of the gaps came from where our users are. The product needed Jalali dates in the date logic as well as the interface, and right-to-left layout across the modeller and the form builder. It also needed form fields that react to one another, without a developer shipping code for each form.
What I did
I went with the third option. Our custom elements behaved like the built-in ones, so undo, validation and saving all worked on them. A layer drawn over the canvas would have fallen out of sync the first time someone pressed Ctrl+Z.
Process designers could also set up how one form field affects another themselves, with no application code shipped for that form. A process step and its form stayed consistent when either one changed.
What I would do differently
I would question building on that library at all. It was much larger than our requirements, and every feature we added had to fit someone else’s architecture. Starting from scratch would have cost more in the first month and less in every month after.