wu-lee
commented
11 months ago A potential point of confusion or tension is that, on the one hand, the existing MykoMap library is configured by a TypeScript data structure passed to the initialiser function; whereas on the other hand you state above that "The goal is that it is not in the deployed code, and can be modified on an existing server."
E.g. This code starts mykomap,
https://github.com/DigitalCommons/coopsuk/blob/189ad2f10a898dad54bd4a2d5193b849b4ce6657/src/index.ts
having included the config from here:
To resolve that we'd probably need to use some sort of validating parser to build a valid config from data. There are 3rd parties which could help with this. But this would limit the variability of the config being built - so we'd need to decide what variability we want to support.
Description
All entities on a mykomap have markers. These markers are used in a variety of ways to classify the different types of organisations and their relationships. For the following use cases:
In a team meeting we decided a good first step will be to enable config that assigns a set of marker rendering attributes to a class. We decided that Mykomaps, at this stage, won't do any clever checking for conflicts (eg if a marker belongs to multiple classes that both have rendering attributes). Therefore we need to make sure in the case that two sets of rendering attributes apply to a marker we can manage this (eg just apply the first/last rendering attributes, whatever is easier).
With this implementation, it is the responsibility of the definer (user/tech support) to ensure that the class-rending pairs make sense. So we don’t need to worry about imposing hierarchy or any clever systems right now. We can just assume that if the user is assigning icons to a class they are doing their best to ensure there are not conflicts. We just have to handle user error without breaking the map.
Being less familiar with the architechture of Mykomaps, I'm not sure if 'adding config' is a clear ask or if this needs some research and proposals agreed upon. In terms of requirements:
I've made this a spike because it feels like there are a lot of questions to answer before we start implementing... but perhaps that's just because I don't know Mykomaps. We might be able to move quickly into implementation, but I appreciate you humouring me :)
Acceptance Criteria
As this is a spike, at this stage I'm just looking for a description of the solution in the comments that answers the following questions:
We want a config that will assign the following marker rendering attributes to a class: icon, colour, transparency.
We need a default rendering for when no class is specified
In the case that two or more classes can apply to a marker ensure that there a rules for how to default.
Maintenance
Future proofing
Additional context
Summary of requirements captured here. Built from other issues in this epic (which I'm hoping to close).