fix(catalog): catalog viewer only shows controls if they are under a group

[tuckerzp]

Previously OSCALCatalog ignored the Controls prop it was passed.
This creates an OSCALControls component to display controls outside
a group.

closes #741
closes #742

Testing

No controls

https://raw.githubusercontent.com/EasyDynamics/oscal-demo-content/main/catalogs/NIST_SP-800-53_rev4_catalog.json

Controls + Groups

https://raw.githubusercontent.com/EasyDynamics/oscal-demo-content/tuckerzp/group-prose/catalogs/basic-test-catalog.json

Just Controls

https://raw.githubusercontent.com/EasyDynamics/oscal-demo-content/tuckerzp/group-prose/catalogs/basic-test-catalog-no-groups.json

---

Groups without controls is displayed the same

---

Top Controls is now shown as a group

---

Top level control groups with prose is displayed

---

Children groups with prose is displayed

---

No groups listed

[tuckerzp]

Note: I still need to add interface documentation

[Bronstrom]

Looking good so far and thanks for adjusting this to typescript.

[kylelaker]

Children groups with prose is displayed

Prose should be displayed above the other children (like we do with controls)

[kylelaker]

Top level control groups with prose is displayed

Can you show this but with controls in the group?

[kylelaker]

If the catalog specifies only controls and not groups, how is it displayed?

[kylelaker]

I am confused about why this needs a specific type -- what part of this causes tsc to lose the ability to infer types?

[tuckerzp]

'subControl' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer. [7022]

'subGroup' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer. [7022]

[kylelaker]

Why does this use a different way to display the list of controls than a Profile does? It seems like when we're listing just controls, those two should use the same code to display the controls?

[tuckerzp]

Why does this use a different way to display the list of controls than a Profile does?

Profile has always displayed lists of controls differently than the catalog does. That may be something to look into at some point. I figured we would not want to remove the accordion like feature the controls in the catalog currently have. I can just have them displayed as we do in Profile.

[kylelaker]

Profile has always displayed lists of controls differently than the catalog does. That may be something to look into at some point

I am not sure why we'd go from having three ways of displaying controls (the way CDef/SSP does it, the way profile does it, and the way catalog does it) to four ways (CDef/SSP, Profile, Catalog w/ Groups, Catalog w/out Groups).

If it's something to look into later, we should open the ticket for that fix now.

[tuckerzp]

If it's something to look into later, we should open the ticket for that fix now.

#816 was created to track that. We may want to refactor it a bit / create a few tasks from it.

[kylelaker]

Thanks for the work on this @tuckerzp and for opening up #816.