feat: Pesist FlowEditor state on route changes

[DafyddLlyr]

What does this PR do?

• Ensures that there's a single, persistent, instance of FlowEditor which is not repeatedly mounted and unmounted on route change.
• This is achieved by removing the depency of the useLoadingRoute() hook fairly high in the component hierarchy. This hook was causing all child components (the majority of the application) to re-render once it resolved - this is what was causing all re-render, and the related flash of unstyled content (FOUC), on each route change.

Also..

• Removes redundant /service-flags and /data routes and components (see comments below about why this was included)

Context

This work has come about as a result of search, but has addressed a fairly long term problem we've been facing with routing.

Search is pretty frustrating as the entire state is reset each time a link / node is clicked. Having delved into this routing / re-rendering issue unsuccessfully in the past, my first thought was to use Zustand to store the state to ensure this is persisted - please see #3672 as an example of what this looks like.

This approach works - but I soon realised that in order for it to be functional it's not just the active tab that needs to be persisted, it's (at least) -

• Search term
• Search results
• Scroll position
• (and reset all of these when I navigate to a new flow)

The same applies to all tabs, and all state within them - clearly this not a viable or maintainable solution.

Solution

It took a lot of digging and frustration to get here! 😅

It turns out that re-rendering is happening due to the use of the useLoadingRoute() hook. This hook triggers a re-render of all children once it resolves and returns a truthy value. Rather than this high-level approach, I think we need a more granular approach to page-by-page loading, or another general solution (routing loading bar?).

Demo

Issue	Before (Staging)	After (Pizza)
FOUC on route change	Screen.Recording.2024-09-14.at.11.00.08.mov	Screen.Recording.2024-09-14.at.11.02.37.mov
FlowEditor state lost when modal opened	Screen.Recording.2024-09-14.at.11.04.35.mov	Screen.Recording.2024-09-14.at.11.06.56.mov

Outstanding questions

How should we handle genuine loading screens between pages, where a re-render isn't a problem?

Some first thoughts -

• Slimline loading bar under header (e.g. https://mui.com/material-ui/react-progress/#linear)
• Per-page, or per-component, use of skeletons (e.g. https://mui.com/material-ui/react-skeleton/)
• Keep DelayedLoadingIndicator, but localised (abstracted into a wrapper?) instead of at a high level
• (Also!) Work on loading less data / be better with caching

We do need some UI here, because whilst removing the FOUC is a big win both visually and in terms of state management (imho!), I do acknowledge that clicking certain links now feels more sluggish as there's a wait between click and visual result. Prime examples here are creating and loading flows.

[github-actions]

Removed vultr server and associated DNS entries

[DafyddLlyr]

Without this, the login page flashed on initial load of the application.

[DafyddLlyr]

This is the single FlowEditor instance, attached to the layout, which persists regardless of route.

[jessicamcinchak]

Big one! Thanks for spending time with this.

Code is looking good, one note/question about some unexpected pizza behavior though

[jessicamcinchak]

Previous issue now fixed and everything else working as expected, thanks !!

[DafyddLlyr]

Moved to draft, hit a bug here where I can't route to internal portals. Will re-open once fixed.

[DafyddLlyr]

I have an implementation of a loading bar here - #3684

Thoughts welcome!