Problem statement
Currently, apps need to implement any operations they wish to do on geometries. It is clear that certain operations get reimplemented in many applications and are common enough that they should be implemented by the framework and exposed through the SDK. There is already an implementation of the area function in esto-studio, but there is no way to use it from the outside.
Proposed capabilities
This is a list of functions for geometries that should be available to apps no matter the technical solution we end up using. The list is now very basic and can evolve over time.
- area
- perimeter
- assigning a label
- suitable point for a label in case the label needs to be customized
Implementation
Before implementing anything, we need to decide on which side of the expression problem we want to be. The current geometries use open polymorphism and there seems to be a global collection of geometries populated at runtime.
Since user-defined geometries are currently impossible and user-defined operations on geometries are common, closed polymorphism seems to make more sense.
The downside would be JavaScript’s lack of support for pattern matching and in order to get the most benefits, we would require TypeScript’s discriminated unions. Similarly, app developers would also get the most out of it only if they were to use TypeScript.
Syntactically, open polymorphism in JS is clearly nicer. However, it would require passing rich geometry objects to the apps instead of raw data. The closed polymorphism approach would simply provide a bag of functions that work on the raw data that apps already receive.
There are also already multiple places in the codebase that define functions for each geometry type, so the current state is already suffering from the problem of having both approaches.
Another possibility is to only make the geometry functions available in the declarative YAML for now, hiding their implementation and postponing the decision regarding open/closed polymorphism. It really only needs to be decided before we release a properly usable version of the SDK.