Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: NASA-IMPACT/veda-ui
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 3e3734a9e02ee982dd8d39a2db3dc5d92ba8b65e
Choose a base ref
...
head repository: NASA-IMPACT/veda-ui
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: d78db829f20ded29218fe1047f1493955bb82480
Choose a head ref
  • 17 commits
  • 5 files changed
  • 4 contributors

Commits on Mar 6, 2024

  1. Copy the full SHA
    0124613 View commit details
  2. Copy the full SHA
    250f49c View commit details
  3. Make updates

    sandrahoang686 committed Mar 6, 2024
    Copy the full SHA
    dfdfa64 View commit details

Commits on Mar 7, 2024

  1. Finish sentence

    j08lue authored Mar 7, 2024
    Copy the full SHA
    7bc1178 View commit details

Commits on Mar 8, 2024

  1. Copy the full SHA
    8278abb View commit details

Commits on Mar 11, 2024

  1. Copy the full SHA
    971cd3a View commit details

Commits on Mar 12, 2024

  1. Update styles for long collection and layer names on dataset cards (#879

    )
    
    Closes Ticket #864
    
    ![Screenshot 2024-03-08 at 11 17 24
    AM](https://github.com/NASA-IMPACT/veda-ui/assets/30272083/7e1df257-c939-405e-a50b-f4efe252570a)
    
    **Changes**
    * Updates the dataset layer cards parent collection name to truncate
    after one line
    * Updates the toolbar menu on cards to stay top aligned to layer name
    * Padding updated to 16px all around
    
    **Validation**
    * Validate that dataset cards look correct with a long title
    * Validate that the parent dataset titles in the **layer selection
    modal** are not affected by these changes and look as they are supposed
    too
    sandrahoang686 authored Mar 12, 2024
    Copy the full SHA
    bb61446 View commit details

Commits on Mar 13, 2024

  1. Rewords options

    sandrahoang686 committed Mar 13, 2024
    Copy the full SHA
    216a2e9 View commit details
  2. Copy the full SHA
    a3fcb94 View commit details

Commits on Mar 14, 2024

  1. Copy the full SHA
    e4ec0cc View commit details

Commits on Mar 15, 2024

  1. Copy the full SHA
    5aec71b View commit details
  2. Copy the full SHA
    708bdcc View commit details
  3. Revert "Add ADR about design system change"

    This reverts commit 708bdcc.
    j08lue committed Mar 15, 2024
    Copy the full SHA
    d4a2b4b View commit details

Commits on Mar 19, 2024

  1. Set status to done

    j08lue authored Mar 19, 2024
    Copy the full SHA
    b469b21 View commit details
  2. Add ADR about VEDA V2 refactor (#875)

    Closes: #865
    sandrahoang686 authored Mar 19, 2024
    Copy the full SHA
    8804ee3 View commit details

Commits on Mar 21, 2024

  1. Cut a release for 4.2

    hanbyul-here committed Mar 21, 2024
    Copy the full SHA
    1a28b04 View commit details

Commits on Mar 25, 2024

  1. Cut a release for 4.2.0 (#895)

    ## πŸŽ‰ Features
    - Optional media attributes for layers:
    #843
    - Add custom javascript injection
    #846
    - ADR for V2 Refactor: #875
    
    ## πŸš€ Improvements
    - E&A imporvement. Related tickets
      - Layer select modal: #845
    - Connect dataset information on layer:
    #821
      - Layer info modal: #849
    - Update data layer card:
    #851
      - Hidden layers: #867
    - Fast follow-ups: #851 ,
    #862,
    #863,
    #860
      - PR template: #880
    
    
    ## πŸ› Fixes
    - Return datasets even when there is a dataset without summaries:
    #786
    - Show all the datasets on Data Catalog page:
    #837
    - Block Map user defined position fix:
    #784
    - Geocoder centering on various projecctions:
    #826
    - Wording, typo: #869
    #854,
    #874,
    - Fix yaxis labeling: #883
    hanbyul-here authored Mar 25, 2024
    Copy the full SHA
    d78db82 View commit details
Original file line number Diff line number Diff line change
@@ -77,13 +77,20 @@ export const ParentDatasetTitle = styled.h2<{size?: string}>`
text-align: left;
font-size: ${(props => props.size=='small'? '0.75rem': '1rem')};
line-height: 0.75rem;
font-weight: normal;
font-weight: normal; ${(props => props.size=='small'? '400': 'normal')};
display: flex;
min-width: 0;
align-items: center;
justify-content: center;
gap: 0.1rem;
p {
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
}
> svg {
fill: ${themeVal('color.primary')};
min-width: ${(props => props.size=='small' ? '1rem': 'auto')};
}
`;

Original file line number Diff line number Diff line change
@@ -49,7 +49,7 @@ const DatasetInfo = styled.div`
flex-flow: column;
gap: 0.5rem;
background-color: ${themeVal('color.surface')};
padding: ${glsp(0.5)} ${glsp(1)};
padding: ${glsp(1)} ${glsp(1)};
border-radius: ${themeVal('shape.rounded')};
border: 1px solid ${themeVal('color.base-200')};
@@ -73,7 +73,11 @@ const DatasetInfo = styled.div`
const DatasetHeadline = styled.div`
display: flex;
justify-content: space-between;
align-items: center;
padding-top: 4px;
`;

const DatasetToolbar = styled(Toolbar)`
align-items: flex-start;
`;

const DatasetTitle = styled(Heading)`
@@ -96,14 +100,14 @@ export default function DataLayerCard(props: CardProps) {
<DatasetCardInfo>
<Header>
<ParentDatasetTitle size='small'>
<CollecticonDatasetLayers /> {dataset.data.parentDataset.name}
<CollecticonDatasetLayers /> <p>{dataset.data.parentDataset.name}</p>
</ParentDatasetTitle>
</Header>
<DatasetHeadline>
<DatasetTitle as='h3' size='xxsmall'>
{dataset.data.name}
</DatasetTitle>
<Toolbar size='small'>
<DatasetToolbar size='small'>
<TipButton
tipContent='Layer info'
// Using a button instead of a toolbar button because the
@@ -140,7 +144,7 @@ export default function DataLayerCard(props: CardProps) {
)}
</TipButton>
<LayerMenuOptions datasetAtom={datasetAtom} />
</Toolbar>
</DatasetToolbar>
</DatasetHeadline>

<DatasetMetricInfo>
100 changes: 100 additions & 0 deletions docs/adr/002-application-architecture-for-configurability.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,100 @@
# Application Architecture for Configurability

* Status: In Review, In Progress, **Done**
* Authors: @sandrahoang686, @faustoperez, @j08lue
* Deciders: @hanbyul-here, @faustoperez, @j08lue
* As of: 2024/03

## Context and Problem Statement

VEDA UI 1.0 was built as a reusable white-label application for independent science data and information projects. These projects should be able to stand up and configure their own instance with their content. The assumption was that projects would reuse the entire application and change mostly the styling and scalable content items such as datasets and stories, and would only need to change a few other elements. The application (pages, functional components; VEDA UI) is separate from content (VEDA config) and pages and elements can be changed via component overrides.

In 2023, our team supported two new projects to integrate VEDA UI for their needs: the U.S. Greenhouse Gas Center (earth.gov/ghgcenter) and the Earth Information Center (EIC; earth.gov). These projects had much wider needs for customization or adaptation, mostly related to the context of the project:
1. Different thematic categorization of content with hierarchies or tags
2. Project-specific headers and disclaimers on several pages, also static / functional ones like the data catalog
3. Changes to navigation - main, secondary, page
4. Additional pages
5. New CMS-typical content types like events or announcements

We are expecting new instances to start using VEDA in 2024.

### Challenge 1: Cumbersome customization to the degree required
Implementing these additional customizations proved to be cumbersome with the current application structure, because they require page overrides and new customization options across the application, which grew fast in complexity.

### Challenge 2: Unconventional combination mechanism for instance configuration and UI components (via Git)
The separation of application and content is currently done via Git submodules: the VEDA UI library source tree is injected into a Configuration project and then they are built together. This works and is lightweight, but is not a very common pattern which is an obstacle for new contributors to the project and new instances.

### Need for a decision: continue to modify, refactor, or rewrite?
The challenges mentioned above have perceivably slowed down our development of new features and made addressing integration project needs cumbersome in recent quarters. We expect the number of instances of VEDA UI to grow, which is great, but makes the need to make a decision whether to make fundamental changes to the application architecture more pressing.

We also need to take into account that the evolution of the application with new and improved features needs to continue and we have limited team resources.


## Decision Drivers

- Investment payoff
- Compatibility with continued support for instances with feature evolution
- Improve developer velocity
- Ease of support for required customizations


## Considered Options

- [1] Continue with current application architecture
- [2] Refactor component library + rewrite instances
- [3] Rewrite component library + rewrite instances


## Decision Outcome

βœ”οΈ [2] Refactor component library + rewrite instances

Move more control to the instance level, modularize the core ui library to expose core feature components and smaller reusable components, and create a data layer as part of the core ui library that is ideally also consumed at the instance level that manages data fetching and MDX parsing so that components are data agnostic.

#### 1. Move Routing from the core ui library to the instance level
Routing and what pages exist should be determined at the instance level. Currently, routing is handled at the core UI library level so supporting additional/removal of pages requires override logic. Moving this to the instance level allows developers/stakeholders to independently manage their routes and pages.

#### 2. Feature components in the core ui library composed at the instance level
Currently, the core UI library handles the composition of each page because of its control over routing. However, pages and what they render should shift to the instance level so developers/stakeholders can control what is rendered within each page view. The core UI library should expose feature components (containers) that deliver a core feature in the VEDA dashboard such as the A&E feature.

#### 3. Modularize and create smaller reusable components
The core UI library should also expose smaller reusable components like date pickers, form elements, analysis tools, etc… (β€œpresentational/dumb” components). This way developers/stakeholders for example can compose a page view with the A&E feature from the core UI library and consume other reusable components to construct their page view. This also now allows developers to build their own custom components on the instance side and directly incorporate them.

#### 4. Create a Data layer that manages all data fetching
The proposed data layer is designed to handle all data fetching, including STAC calls, and MDX parsing. Think of it as a versatile data utilities library. Introducing this layer would enable components in the core UI library to remain data-agnostic. In the event of scaling to additional or different data sources, expansion can be easily accomplished by integrating them into this centralized layer. Smart components (larger and stateful) would then efficiently consume this data layer.
> **Integrating with [stac-react](https://github.com/developmentseed/stac-react/tree/main)**: Because these React hooks manage data fetching to the STAC API using the Context API provider pattern, this could just be used directly as it is already its own data layer. We would have to decide where we wrap the Provider though. Ideally, at the instance level, we would wrap the provider at the highest level in the tree either around the router or specific view containers and then consume these hooks down the hierarchy on the instance side. The components in the core ui library would be prop driven so this way they can be truly data agnostic and accept whatever data passed in.
**Architectural Diagram of the Refactor**
![Architectural Diagram](./diagrams/veda-v2-refactor-adr-dataprovider-diagram.png)

*[Miro Board Link](https://miro.com/app/board/uXjVN6lkBnc=/?share_link_id=85040810316) which documents team's brainstorming discussions, options considered, technical trade-offs, and final proposed solution in detail*


## Pros and Cons of the Options

### [1] Continue with current application architecture
- πŸ’š No up-front cost
- 🚩 Fulfilling the customization requirements means making the app more customizable through overrides, options, and flags/branches in code, increasing complexity, which has a cost in terms of developer velocity and onboarding


### [2] Refactor component library + rewrite instances
- πŸ’š A component library allows for more straightforward composition into applications with the customization (pages, layout, navigation, routing, data providers) that is required
- πŸ’š More efficient delivery of new instances with modified page views, without directly impacting the core UI logic library. Seamless support for a wider range of data integrations.
- πŸ’š As we refactor, we can see the new patterns emerge and hopefully implement feature improvements together with architecture improvements. However, rebuilding the instances with the components will basically mean a rewrite.
- 🚩 Refactoring is a complex process - risk of delay / failure.
- 🚩 The new architecture may demand deeper coding knowledge to set up a new instance. However this complexity is offset by the fact that making overrides in the current architecture is equally developer-intensive. We plan to establish a template instance that is easily cloneable for a quick start when spinning up new instances.


### [3] Rewrite component library + rewrite instances
- πŸ’š A component library allows for more straightforward composition into applications with the customization (pages, layout, navigation, routing, data providers) that is required
- πŸ’š More efficient delivery of new instances with modified page views, without directly impacting the core UI logic library. Seamless support for a wider range of data integrations.
- πŸ’š Faster development without requiring specific domain knowledge on very custom dependencies.
- 🚩 Since we also need to continue supporting the current instances, we would need to invest into the rewrite while we also keep developing the current application. This offsets any returns on investment and increases the risk of failure.
- 🚩 The new architecture may demand deeper coding knowledge to set up a new instance. However this complexity is offset by the fact that making overrides in the current architecture is equally developer-intensive. We plan to establish a template instance that is easily cloneable for a quick start when spinning up new instances.


## Resources
* [Github Issue to gather strategic questions related to future of VEDA UI](https://github.com/NASA-IMPACT/veda-ui/issues/766)
* [Refactoring vs Rewrite article](https://methodpoet.com/refactoring-vs-rewrite/)
* [Team Brainstorming session for VEDA V2 Refactor Miro Board](https://miro.com/app/board/uXjVN6lkBnc=/?share_link_id=238172590342)
* [Stac-react Repo](https://github.com/developmentseed/stac-react)
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
2 changes: 1 addition & 1 deletion package.json
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
{
"name": "veda-ui",
"description": "Dashboard",
"version": "4.1.0",
"version": "4.2.0",
"author": {
"name": "Development Seed",
"url": "https://developmentseed.org/"