Improve Profile Viewer performance & user experience

[Bronstrom]

Due to lengthy rendering, the Profile Viewer takes a long period of time to show elements on the page. In order to improve the user experience, a skeleton framework has been added to display on the page while rendering the resolved controls. To improve performance, a few areas of OSCALProfile, OSCALControl, & underlying components have been optimized. Most notably, the modifications data sent between components have been slimmed down.

• resolves Improve Profile Viewer Performance/Loading Display #74

[Bronstrom]

I wanted to note the live sandbox environment seemed to already run the FedRAMP moderate profile in about 2 or less seconds (as desired in the Acceptance Criteria). There seems to be a performance drop with it locally, especially when using the reload button after a few times. I was able to shave a couple seconds off when running it locally - which I think will still show a noticeable change on AWS.

[kkennedy26]

I got this error when running locally and clicking to the profile viewer.

[Bronstrom]

I got this error when running locally and clicking to the profile viewer.

@kkennedy26 I was using the FedRAMP profile as the default profile when testing. I just realized the NIST profile doesn't have set-parameters. I'll make a fix for this.

[kylelaker]

This looks great and I am really excited about the potential improvements here! There are a lot of changes. Can you talk about how specifically this was optimized? Are there performance benefits to function over const X = () => {}?

[Bronstrom]

This looks great and I am really excited about the potential improvements here! There are a lot of changes. Can you talk about how specifically this was optimized? Are there performance benefits to function over const X = () => {}?

Of course - I was a bit vague about optimization. The arrow functions (const X = () => {}) create a new function every time components are re-rendered. To avoid this, the "function" keyword can be used instead. Arrow functions are apparently good in less dynamic contexts. For more information see: 5 Ways to Optimize Your Functional React Components - Avoid arrow functions when possible and When (and why) you should use ES6 arrow functions. I also made the choice to split up the modification attributes, set-parameters from alters, to lessen the amount of data shared between underlying components. This should help with the efficiency of OSCALControlProse and OSCALControlModifications, which are doing a lot of the work.

[kkennedy26]

Looks good. Can definitely see the improvements in load time with Profile Viewer since the recent commit

[Bronstrom]

To further improve performance, I had the idea that more data could be filtered out of modifications (it appears to be what's taking the longest time to load and render), such as getting rid of the removes attribute in modify.alter. Although, we will probably be using this data soon in a future issue (EGRC-407). I was also looking into useMemo() and useCallback(), but there doesn't seem to be a function that's being repeatedly rendered in the same exact way (like with how the control ID parameter is unique for rendering the majority of functions) or they would minimally help. The functions I attempted these on seemed to have a lot of overhead causing the Profile Viewer to stagnate more. Let me know if anyone has a different opinion or guidance on this.

[kkennedy26]

Just realized I didn't approve this in my previous comment but meant to haha.. good work