search

NASA-IMPACT / veda-ui

Frontend for the Dashboard Evolution project
Other
22 stars 5 forks source link

ADR - managing thematic areas #7

Open olafveerman opened 3 years ago

olafveerman commented 3 years ago

The new dashboard will have some sort of notion of 'instances'. Figure out how instances will be managed in new version.

Assumptions for the Climate Dashboard:

image Preliminary wireflow of the main landing page + theme landing page

The core dashboard will be reused by other projects, that don't necessarily have Thematic Areas nor the need for a common landing page.

danielfdsilva commented 3 years ago

The first option we considered for the management of instances was to have separate deployments for each one.

This meant that each instance was an individual site, could be hosted in a different domain and allow for more complex code overrides. However this also meant that theme switching would not be straightforward and every time it happened, all the resources would have to be loaded again (since we're talking of different sites)

The dashboard landing page would be an additional site (albeit simple one - probably static) that would link to the other ones.

Working with the assumption that theme switching is core to the application and that a user will explore multiple themes during a visit we consider it to be a better solution to house all the themes under the same application. With this approach the different themes will appear more cohesive and switching between them won't require the assets to be loaded again. A downside is that the customization of different instances will be reduced but with a good configuration scheme we can ensure that the needed options are covered.

Another limitation is that the different themes will have to live under the same domain, being differentiated by a path parameter (ex: http://example.com/theme1, http://example.com/theme2)

If the dashboard needs to be used for another project that doesn't have the concept of themes, this approach still holds, as we can disable the hub pages when there is only one theme defined - this would result in a dashboard that has, in practice, no concept of theme.

To meet these needs we propose that the code is organized the following way:

danielfdsilva commented 2 years ago

I'm still running some tests as to how to make this work with the app's build system but want to write down some thoughts to get your buy-in.

To allow the app to be reused for different scenarios it is a core tenet that it should be easily configurable. To achieve this I'm looking to have the app's core code separated from the configuration.

In practical terms this means that every time a new instance of the app is needed, the user can just clone the config-repo, add content and configuration, and run. Updates to the UI part of the app are done independently and it is up to the user to decide to upgrade (same as one would do for node_modules for example.).

delta-treemap This image roughly details the app data structure. The app lists thematic areas, and for each thematic area there are datasets and discoveries to explore.

My proposal goes something along these lines:

For the purposes of this example I'm assuming the project's codename to be Delta.

delta-ui

Repo with the UI code.

delta-config

This repo contains all the content and configuration needed for the UI to be built. Exmple

.delta/                   -> Scripts and base stuff needed for this to work

delta.config.js

thematics/
  fire.thematics.mdx

datasets/
  no2.data.mdx

discoveries/
  history.discoveries.mdx

Keeping the "thematic areas", "discoveries" and "datasets" all in separate folders allows for the possibility of content being reused. (Example: a dataset that belongs to multiple thematic areas)

delta.config.js
Contains the base config for the build. For example:

module.exports = {
  // Where to get data
  thematics: './thematic/*.thematics.mdx',
  datasets: './datasets/*.data.mdx',
  discoveries: './discoveries/*.discoveries.mdx'
}

MDX
All mdx files would have roughly the same structure with some frontmatter at the beginning to hold configuration, and then the content for that element in long form.

Example: fire.thematics.mdx. The content of the "Thematic area" would go into the Thematic area's about page.

---
id: fire
name: Fire
description: Stuff about fire.
---

## Fire

Content about this.
<MyMDXomponent />

Discoveries & Datasets Following the same format they would be connected to a thematic area though frontmatter configuration.

---
name: History of elements
thematics:
  - fire
  - water
---
Content goes here. Im MDX

@olafveerman @leothomas @abarciauskas-bgse @anayeaye thoughts?