Open nerik opened 1 year ago
After meeting with the team, this is our proposed approach to this problem:
The immediate short term approach relies on using embed blocks. Users will be able to create tools off of VEDA and then include them in stories.
The long term solution caters to more advanced use cases and it is geared towards developers.
These will be custom developed on a use-case basis using existing components or crafting new ones as needed (which can then be added to the veda-ui
pool of components), and custom code.
The code for these interactive pieces will live in each instance of VEDA and will be able to be used in MDX documents (as blocks) or on custom pages.
The custom pages that can be created (option to the user) to host these custom visualizations will be collated under a common hub called tools (name pending). The tools hub will be accessible from the main navigation and will be instance specific. Each dataset overview page will link to the tools that are relevant to that dataset.
From https://github.com/NASA-IMPACT/veda-architecture/issues/290
We currently have two specific use cases for this:
This is a ticket to lay down the different design and technical frontend decisions we'll have to make for this to be sustainable long term.
Where in the dashboard for the users?
We've pretty much already eliminated hypothesis NASA-IMPACT/veda-config#1 as there is already an ongoing refactor of this area of the website. Options 2, 3 and 4 would make use of the infrastructure already in place, especially rendering MDX blocks. Option 4 has been suggested to improve discoverability.
Where should use-case specific code live?
veda-ui
veda-config
or other config instanceThe advantage of option 1 would be to facilitate the reuse of use-case-specific logic across several instances. There's no clear use case of sharing datasets across instances, however, one could easily assume that common behaviors could be shared (thinking of the marker + popup example). Option 2 however would likely encourage faster iteration cycles as we don't have to worry about reusability or over-abstracting things. Having runnable code living inside a repo named
*-config
irks me a little bit but I guess it's already the case with MDX anyways. We could always consider option 3 if very complex/very specific use cases arise.API
How do we provide hooks into the VEDA ecosystem to develop fully custom experiences? One assumes here that potentially we (the team at DS) would not necessarily be the ones building the new features/experiences.
TBD
See: https://github.com/NASA-IMPACT/veda-ui/blob/main/docs/content/PAGE_OVERRIDES.md https://github.com/NASA-IMPACT/veda-ui/blob/main/docs/content/CUSTOM_PAGES.md
cc @danielfdsilva