We have reached a point where different users can have different needs. We want to be able to implement something that allows them to have a bit of customization, so for instance each project can have a different graph or set of graphs on the model selection page.
There are many ways to do this. For example:
Show all suitable graphs by default, but allow users to click a button on graphs to hide them; so in the model selection graphs use case, we would show both model selection graphs, but a user who only wants the grid would click a button to hide it. This choice is serialized, maybe to a YAML file, and that component would just be hidden by default.
Instead of involving user input in the UI, a YAML file with boolean flags for each component is provided.
We build out different pages/endpoints for different projects, and the YAML configuration decides which endpoint is mounted to the root '/'
I'm leaning towards #2 right now. #1 is more complicated to add UI elements for doing this, and #3 probably lets too many project-specific details bleed into a generic repo.
We have reached a point where different users can have different needs. We want to be able to implement something that allows them to have a bit of customization, so for instance each project can have a different graph or set of graphs on the model selection page.
There are many ways to do this. For example:
Show all suitable graphs by default, but allow users to click a button on graphs to hide them; so in the model selection graphs use case, we would show both model selection graphs, but a user who only wants the grid would click a button to hide it. This choice is serialized, maybe to a YAML file, and that component would just be hidden by default.
Instead of involving user input in the UI, a YAML file with boolean flags for each component is provided.
We build out different pages/endpoints for different projects, and the YAML configuration decides which endpoint is mounted to the root '/'
I'm leaning towards #2 right now. #1 is more complicated to add UI elements for doing this, and #3 probably lets too many project-specific details bleed into a generic repo.