[Spike][Mykomap] Bespoke marker rendering

[lin-d-hop]

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:

• Differentiating - members and non members
• Differentiating - org type
• Custom markers - bespoke
• Customer markers - icon set
• Custom markers - logo
• Distinguish between data sets and data quality

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:

• End users don't need to be able to update this config. It can be created by MM tech support.
• The goal is that it is not in the deployed code, and can be modified on an existing server.
• Considerations on implementation strategy are ease and maintenance -> if there is something that will take a few hours longer that is much easier to maintain afterwards, let's do it.

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:

1. We want a config that will assign the following marker rendering attributes to a class: icon, colour, transparency.

• Where is this config?
• How will it be updated by DCC 'tech support' (us)?
• What format will the rendering attributes be specified?
• How does the config match to a 'class'?

2. We need a default rendering for when no class is specified

• How is this specified in the config?
• How is it handled if it is missed in the config?
• How to catch/prevent incorrectly specified config?

3. In the case that two or more classes can apply to a marker ensure that there a rules for how to default.

• What is the simplest way to do this?

4. Maintenance

• What happens when the config changes? Does the server need deploying? Or is this automatically read? Can this be done on a live prod server/map instance?
• How to catch/prevent incorrectly specified config?

5. Future proofing

• Again, less familiar with Mykomaps. There are plans to enable mulitple maps on a single server. Can we create config that supports this?
• Are there other future proofing factors to consider?

Additional context

Summary of requirements captured here.
Built from other issues in this epic (which I'm hoping to close).

[wu-lee]

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:

https://github.com/DigitalCommons/coopsuk/blob/189ad2f10a898dad54bd4a2d5193b849b4ce6657/src/config.ts

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.

[wu-lee]

I'd done a bit of research on the validation topic before, but lost the links. I think I was looking at runtypes. Looking again, I find these:

• A post about runtime validation, mentions the following libraries
• ts.data.json - a typescript-type-aware validation library
• An article describing ts.data.json - Decoding JSON with Typescript
• Zod - a popular validation library:
• A "Zod 101"
• A Reddit thread on your favorite data validation library