feat: add generic display of properties

[Bronstrom]

This creates a generic OSCALProperties component and adds it to back matter, controls, and metadata.

Testing

Try out the following catalog in the Catalog Viewer/Editor: https://raw.githubusercontent.com/EasyDynamics/oscal-demo-content/brad/test-catalog-generic-properties/catalogs/generic_properties_test_calalog.json

Closes #718

[kylelaker]

Very early thoughts. There are a few design things not written here that we should talk through. I will try to summarize those and provide more info soon.

[tuckerzp]

Just had a quick look over things as they are. I had a few comments.

I also am not sure I understand why namespaceOf can't be used instead of isNistNamespace. I didn't have a ton of time to think it over, so maybe I am missing something.

Accidently hit approve

[Bronstrom]

Just had a quick look over things as they are. I had a few comments.

I also am not sure I understand why namespaceOf can't be used instead of isNistNamespace. I didn't have a ton of time to think it over, so maybe I am missing something.

namespaceOf returns a namespace or the default NIST namespace when there is no namespace provided. isNistNamespace validates the namespace being a NIST namespace, which is true when ns is empty or an empty string. This validation check is done a few times within OSCALProperties and I thought it made sense to be a function. This could be turned into namespaceOf(ns) === NIST_DEFAULT_NAMESPACE if we wanted to use that function inside of this one.

[tuckerzp]

I discussed this briefly with @Bronstrom, but I wonder if filtering out non nist namespaces to a separate list to only then put it in more or less the same list is the best approach.

To me, this feels more like we need to sort. Anything that is considered to be in the default namespace (found preferably using namespaceOf and a boolean check) would be put at the top of the list while everything else can just remain in the same order.

I honestly am unsure if this cleans up the code a ton, but conceptually it makes more sense to me in terms of what we are actually trying to do. I also think it will make the return statement of the component a lot cleaner. Feel free to ignore me if I am wrong here or this is too big of a change 😆

[kylelaker]

To me, this feels more like we need to sort. Anything that is considered to be in the default namespace (found preferably using namespaceOf and a boolean check) would be put at the top of the list while everything else can just remain in the same order.

Are you suggesting something like:

function compareNamespace(a: Property, b: Property): number {
  if (namespaceOf(a) === namespaceOf(b)) {
    return 0;
  }
  if (namespaceOf(a) === NIST_DEFAULT_NAMESPACE) {
    return -1;
  }
  if (namespaceOf(b) === NIST_DEFAULT_NAMESPACE) {
    return 1;
  }
  return namespaceOf(a).localeCompare(namespaceOf(b));
}

const sorted = props
  .sort((a, b) => a.name.localeCompare(b.name))
  .sort(localeCompare);

That feels immensely complicated compared to filtering. And then we're just encoding that information in the sort order...

[Bronstrom]

Here's some screenshots of how the modal is looking:

[kylelaker]

Small iconography change and then I think I am good to move forward with merging.

[kylelaker]

Oh! We also need a storybook file for this! At least for the OSCALProperties dialog itself

[kylelaker]

Suggested change

	interface OSCALPropertiesDialogProps {
	export interface OSCALPropertiesDialogProps {

[Bronstrom]

Good point!

[kylelaker]

Thanks for your work on this!