✨ Archetype form for Create and Edit

[sjd78]

Add the Archetype form along with Create and Edit actions from the archetype table.

MSW stubs for the hub archetype api are enabled by default for now.

Resolves #1265

Screenshots

Create new (empty):

Tag selection field open with typeahead active:

Create fully filled in:

Create in error with an archetype name that already exists:

Edit existing:

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.01% 🎉

Comparison is base (ccafe8d) 42.39% compared to head (50812df) 42.40%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1343      +/-   ##
==========================================
+ Coverage   42.39%   42.40%   +0.01%     
==========================================
  Files         137      137              
  Lines        4291     4292       +1     
  Branches     1007     1008       +1     
==========================================
+ Hits         1819     1820       +1     
  Misses       2460     2460              
  Partials       12       12              

Flag	Coverage Δ
client	42.40% <100.00%> (+0.01%)	⬆️
server	∅ <ø> (∅)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
client/src/app/components/Autocomplete.tsx	33.57% <100.00%> (+0.47%)	⬆️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ibolton336]

I think this is in great shape and would be happy to merge it at this stage if we want to push the remaining open tasks to later PRs.

[ibolton336]

I was wrong about this field needing to be surface on UI level. This is an internal hub construct. We only need to pass tags as they are passed on applications today.

[sjd78]

Humm -- I still think that the 2 tag files are needed on UI...

1. Criteria, so people can choose the tags that go in to the archetype-application matching algo
2. "Static" archetype, so people can choose tags that should be associated with applications just by being matched to the archetype

There is a difference between what types the form values have and what is in the data model. Currently, the Autocomplete component only supports a single list of strings for everything. That doesn't line up nicely with an array of Tags or similar. Thankfully when I tested creating Tags from curl, the names did need to be globally unique (regardless of what tag category tags belong to), so the current impl of Autocomplete is sufficient.

[ibolton336]

@sjd78 I think the hub is taking care of that logic for us. It should work similarly to how the application form works. Can just pass tags as they are. The hub should know which tag belongs to what category & what tags are used in the matching logic.

As far as the autocomplete component goes, I think we should just show the list of tags with no category for this first pass. And address the missing visual component of showing the associated category after feature freeze.

[sjd78]

Sure. The form will display whatever data is provided for an edit and just empty values for a new archetype.

The form interface uses a string[] instead of a TagRef[] so the Autocomplete component is easier to use (via the ItemsSelect wrapper component).

As for the "criteria tags" and "archetype tags" fields, they are both still required inputs on the enhancement: https://github.com/konveyor/enhancements/blob/90b827b68cc367284a66bf66f087d5c263487e05/enhancements/assessment-module/README.md#creating-new-archetypes

Are you talking about swapping the actual Archetype API model from Tag[] to TagRef[]?

[sjd78]

I think this is in great shape and would be happy to merge it at this stage if we want to push the remaining open tasks to later PRs.

I'd like to throw the Stakeholders in there with the autocomplete and then move forward. That shouldn't take me much more time today after sorting out how to use Autocomplete for tags.