React + Patternfly Component Interest Group

Development
#1

Background

pulpcore provides “Master models” which provide fields common to all plugins, and then plugins subclass to create a “Detail model” which is the concrete model plugin users will interact with and can define content-specific fields there too. For example pulpcore provides Remote which provides these fields. Then plugin writers can subclass to make a RpmRemote or a CollectionRemote.

Motivation

There is a general need to have UI components in front of Pulp APIs. For example the galaxy_ng team wants to have UI components talk to various Pulp APIs. They use React + Patternfly

Idea

What if we create generic React + Patternfly UI components representing pulpcore’s “Master models”, e.g. Remote, Repository, Content, Distribution, etc. Then these can be “customized” into detail components, e.g. RpmRemote or a CollectionRemote as derivative React + Patternfly components.

Value

These components aren’t a UI themselves, but they are the building blocks of one, allowing others to use these base components to create various UIs on top of the Pulp APIs.

Feedback

Please share your thoughts on this idea. Also please share if you would like to be involved maybe as a tester, contributor, end-user, etc.

4 Likes
#2

I see 3 possible ways to approach this:

  1. UI reads (extended) model info at run time from the API
  2. UI reads model info at compile time, possibly from (extended) API schema or other sources
  3. UI encodes model info at write-time, manually updated when models change

option 1 would mean the UI always up to date with the current version, and supports all enabled plugins (if they do the thing), but it would also require extending django models with metadata such as localizable field labels, UI component types (the current model probably doesn’t distinguish between comboboxes and radiogroups), js-compatible validator regexes, hrefs for select options, required fields, help text and such; would require devs to update these when making model changes, and would require an API to access them (including for all the plugins); the UI part would then deal only with converting this metadata to real react components to render, and knowing where to save/load

option 2 is pretty much the same, except moving this to compile time might make it easier to read the data from multiple sources, have extra field metadata in the UI code and tests that the 2 sets of fields still match … but needs a list of supported plugins and won’t allow other plugins to change the ui

option 3 is the easiest to do if the models don’t change too much, but is the one that needs a human-level process to happen whenever models change (and be tied to a specific set of pulp versions and plguin versions, and a list of plugins; other plugins won’t change anything)

Which do you think would be the right approach?

… also, I’m just assuming … this is about creating and editing instances of those models, right?
Or would there also be a concept of custom callable actions? (As in not just crud but also eg. purging a namespace, archiving …a thing, triggering a sync action on a remote…)

#3

Second topic, how generic do we really want to be, there is no such thing as a generic UI, if we do Patternfly + React, at best other Red Hat UIs will be able to use it.

There are options such as https://data-driven-forms.org/ (which supports multiple UI framework backends) and we should indeed consider it especially if going with option 1 from above, but it also makes it a bit harder to integrate in galaxy, so it’s not necessarily my first choice if we have no other candidate users.

#4

I share your concept with being too generic. Generating a ui from the generated api-docs sounds scary to me. For the same reason, we do not generate any pulp-cli commands. The result would just be unusable. Instead we provide a rich library of building blocks for patterns we find again and again.

BTW count me in for the interest group, maybe even as a contributor.

#5

OK, so sounds like we should rescope this to creating a set of composable Patternfly/React UI components for creating/editing various pulp entities?

Is Remote, Repository, Content, Distribution the full list?
(looking at app/models, I’m pretty sure things like “acs” or “exporter” are not something we would want UI for, but I can’t tell if there’s anything else that should be on the yes list?)

1 Like
#6

I would also like to join the interest group.

#7

I’d like to join as well.