bgrant0607
commented
2 years ago We'll also want a mechanism for grouping resource types in navigation.
Most of supported resource types currently relate to Namespaces and Namespace-scoped policies.
When we add application resource types (https://github.com/GoogleContainerTools/kpt/issues/3351), that will add quite a few more.
Support for Config Connector would add even more.
Some types, such as Kptfile and ApplyReplacements, are independent of specific use cases.
Most of the UI plugin is general-purpose, except for resource-type-specific code.
That code is currently spread across multiple files and directories: https://github.com/GoogleContainerTools/kpt-backstage-plugins/tree/main/plugins/cad/src/types https://github.com/GoogleContainerTools/kpt-backstage-plugins/blob/main/plugins/cad/src/components/ResourceEditorDialog/components/FirstClassEditorSelector.tsx https://github.com/GoogleContainerTools/kpt-backstage-plugins/tree/main/plugins/cad/src/components/ResourceEditorDialog/components/FirstClassEditors https://github.com/GoogleContainerTools/kpt-backstage-plugins/blob/main/plugins/cad/src/components/ResourceViewerDialog/components/FirstClassViewerSelector.tsx https://github.com/GoogleContainerTools/kpt-backstage-plugins/tree/main/plugins/cad/src/components/ResourceViewerDialog/components/FirstClassViewers/StructuredMetadata/resources
and possibly other places.
It would be useful for resource-type-specific implementations to be self-contained, so that they could be easily added, eventually without a fork of the plugin. That would enable other projects to add types relevant to them: Kubernetes types, Config Connector types, ArgoCD types, Gatekeeper types, Istio types, etc.
At least until we're able to autogenerate UI forms from resource definitions. :-)