feat: add demo activity-ui components #19
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As I was building out the new activity API, I needed a way to quickly validate that the API was working as I was expecting without having to build a separate application, run the cloud/staff portal, or require me to use the API. This got me thinking about long-term how we wanted to manage UI components that are specific to a service or a product (Activity, DNS, Proxy, etc).
What if each service that exposes an API, also exposes UI components that are designed to be used with that API?
I used Claude to prototype creating a new
uipackage within the activity repo with the goal of exposing UI components that are designed to work with the Activity API provided by the repo. My thinking was these components could build on a shared UI library that provides Datum's core design components / features.Important
I do not want to merge this PR as is. This PR is only to demonstrate how we could consider exposing UI components from a repo that can be imported into a UI like the cloud portal or staff portal.
I'm hoping we can get alignment around where these product specific components should live long-term. My thinking was that if the UI components are baked into the same repo that provides the API, we can easily do automated functional end-to-end testing since I can stand up a full new environment with the API and UI in place and have end-to-end tests confirm both the API and UI are working as expected. This would also mean the API and UI components are versioned together.