VEDA UI components integration

[sharkinsspatial]

During our team week eoAPI hacking session, @abarciauskas-bgse @oliverroick and I had a chance to sit down and do a bit of high level thinking about how the work being done on the stac-explorer UI can best be generalized for use with other similar projects, most notably veda-ui. A lot of the discussion was based around improving my ideas for STAC API driven self-configuring components. @oliverroick made the excellent point that we don't want to enforce component design and structure on developers and we should instead be focusing on only a library to handle

1. STAC API request construction and response management.
2. STAC API response -> state/context management and standardized props propagation.

This way developers have all of the hard, drudgery work of interacting with the STAC API handled for them and they only need to worry about designing a great UX that can handle standardized props.

@mmcfarland has already done the bulk of the heavy lifting STAC API typing, query generation and titiler-pgstac mosaic integration but this work is unfortunately deeply embedded in the PlanetaryComputerDataCatalog codebase. To continue building out stac-explorer in a way that will also be usable for the veda-ui we need to restructure this code and move it into a standalone package. I think we can do this in the stac-explorer repo in the near term. I'll let @oliverroick correct me here when I use the incorrect terminology, but we discussed a few design goals to guide this work

1. Move as much application/component configuration as possible into STAC structures at the Collection or Catalog level (this should work with both static STAC documents and API served STAC endpoints). This makes the library much more usable to the wider community who is already using STAC rather than forcing them to build custom configuration at the dataset level as we currently do with the veda-ui codebase.
2. Simplify API data fetching and caching by using a standard library like tanstack/query.
3. Provide examples of using the centralized STAC API state via useContext and useReducer with sample components.
4. Provide examples of using the centralized STAC API state with react-map-gl components with the controlled approach with a footprints and mosaic tiling sources configured by standardized props defined in the library.

This was gist of most of the conversation. We also discussed how we can make these abstractions easily usable across other UI projects. It will be great to get feedback from folks working on the veda-ui restructure so that we can make this API request/state management library an easy drop in for STAC API and Titiler interactions if they would like to use it.

[j08lue]

Thanks for this great write-up, @sharkinsspatial.

Just for the record here - I very much share your vision of having an abstracted, nicely defined (STAC) data layer that VEDA UI features can connect to.

It is so easy to rely on static app content for data, since you control that information and structure. But you so easily end up with bespoke data models that are a huge obstacle for interoperability. I hope we will be able to move away from that and build dashboard / data exploration UIs that delegate more of their data model to STAC and use standard integration patterns.

[oliverroick]

In addition, I was thinking about the conversations we had during team week and the things we’ve been working on over the last couple of months, I feel like there might be a case to develop a STAC UI library. Over the past few years Development Seed has been building front-ends to STAC catalogues in various ways. We’ve build projects for clients like VEDA and IFRC, and we’ve build more experimental projects like stac-admin or stac-explorer. Each of these applications share common features like listing collections items, displaying item and collection bounding boxed on a map, searching and filtering catalogs by geography, time or collection.

Plus, clients asking us for custom features, which often aren’t a good fit for a generic application. So instead of trying to build one-size-fits-all solution, like I tried with stac-admin, maybe the way to go is to have a set of STAC-related UI building blocks that we’ll use to put together custom solutions for clients.

There is a lot of repetition and we might want to consider a library of UI building blocks that allows us to put STAC front-ends together. It will provide a set UI components to display STAC data, such as lists and maps of collections and items, self-configuring forms based on a catalog’s querables, or forms to edit STAC metadata. This library would be more opinionated than stac-react; we would want to decide on things like theming, how we manage form state, we might even pick a base library like Chakra so we don’t start from scratch. I don’t see this as an open-source library, culturally speaking, we can open-source it but the target audience will be us internally.

---

Just an idea, I realise that there is a lot of things to consider like maintenance and governance, and who make decisions and how. But I’m curious to hear from VEDA folks if this might be useful in their context too.

[j08lue]

library of UI building blocks that allows us to put STAC front-ends together

I follow the idea of a STAC UI library tailored to use cases we know, but open-sourced.

Perhaps we can use the context of the planned VEDA UI refactor as a good case to see whether we can identify generalizable components that could be ejected into a separate library?

The steps we need to take towards this vision, @sharkinsspatial and @oliverroick, are a bit hard for me to identify, since they depend on the internal logic of STAC-based applications like VEDA UI, which I am not super familiar with. Let's discuss how we break this down.

What I can easily follow is the vision of VEDA UI turning into an application that relies more on STAC for the configuration of its content. Like this concrete case, which may be one of the first ones for us to tackle:

• https://github.com/NASA-IMPACT/veda-ui/issues/884