🪟🔧 Connector builder: Performance improvements

[flash1293]

Some experimental performance work:

• Replace state+effect with useMemo where possible
• Split up context
• Memoize places that seem fitting (especially around formik as it's very trigger happy)

There is some positive effect - here the react commits for this PR (scenario is adding one character to the base path).
The tooltip is showing the render time of the highest bar to make things more comparable (see cumulative sums down below).

vs master:

There's one commit less and you can see how in the latter one each commit takes the same amount of time because it's always the whole app re-rendering, while this PR there's more variance because some commits are only updating parts of the app (e.g. once the response from the server arrives only the testing panel gets updated, not everything)

However, the positive effect is not huge, probably because now there is more work done to check the memo boundaries - around 25% faster (100ms to 130 ms cumulative render time which 6x CPU slowdown).

I didn't try, but I have the suspicion that adding more fine-grained memoization (like discussed with a memoWithBuilderState higher-order-component) won't necessarily reduce the cumulative render time by much

My summary:

• No huge low hanging performance fruits in there at the moment
• Might become more relevant in the future though because the app will get more complex and always re-rendering everything multiple times will get more and more expensive
• Formik is re-rendering a lot - a render of the base component will definitely render every place that's tapping into the context in some form (something to keep in mind to make things easier later on). I think we can shave off some time here but it would be harder to achieve and make the code more complex.
• No pressure on doing any refactorings at the moment, but we should keep an eye on this - the current structure might also get hard to grok at some point when we keep adding features

[lmossman]

I tried testing this locally and I noticed an issue: when you add a stream, that stream is not available in the test panel stream selector dropdown until you switch the stream view manually (either in the sidebar or in the stream selector).

I spent a few minutes looking into this and I found that the lastValidBuilderFormValuesRef.current is properly being updated when a new stream is added, but I think the issue is that this doesn't cause the FormState provider to re-render, so is doesn't get propagated to lastValidBuilderFormValues and therefore doesn't get propagated to lastValidJsonManifest or to the TestState so a streams/list call is not made.

Only once the focused stream is manually changed does all of the above happen since the state provider gets re-rendered in that case.

[lmossman]

What is the reasoning behind putting testStreamIndex in FormState instead of TestState?

[flash1293]

It's a little annoying so many places need to subscribe to the test state, solely because they want to set the test stream index.

But actually while looking into it a bit deeper I found a better way to handle that - instead of explicitly setting testing stream index and view index to the same value, I added a hook to the new test state service to handle that. Makes things much simpler and is a better separation of concerns.

[flash1293]

I tried testing this locally and I noticed an issue: when you add a stream, that stream is not available in the test panel stream selector dropdown until you switch the stream view manually (either in the sidebar or in the stream selector).

Took me a while to figure it out, but it should work fine now. The problem was that it would update the ref after setStoredBuilderFormValues is called - however that call directly triggers a new react render, so the ref was outdated. Switching the order made it work.

[lmossman]

Changes LGTM, tested locally and it is working as expected