fix(dataplanes): show dataplane info even when /stats fails

[johncowen]

I found a tiny loading/error bug whilst working on something else.

TLDR: There was a DataLoader waiting on traffic but not erroring on traffics error. When I looked at it I don't think we should be using a DataLoader (neither a loader nor an error) and just wait for the data and show the rendered ui once its loaded. Errors are dealt with via error notifications elsewhere.

I added a little test to prevent future regressions (and tested it breaks on master)

Previous to this PR, the About Dataplane box would show an eternal loader if this errored (relatively common) even though it could show all of the data about the Dataplane.

[netlify]

✅ Deploy Preview for kuma-gui ready!

Name	Link
🔨 Latest commit	9c06a9d
🔍 Latest deploy log	https://app.netlify.com/projects/kuma-gui/deploys/699c960831b1260008c998a3
😎 Deploy Preview	https://deploy-preview-4645--kuma-gui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[schogges]

Why did you move DataplaneRouteGuard and RootView? They were intentionally kept in legacy-data-planes because ones we can remove the legacy parts of data-planes we can also remove the route guard and root view. So everything that can be removed was kept in legacy-data-planes 🤔

[johncowen]

Oh sorry should have said:

It took me a while to figure out what the routing structure was here and I moved it a little to make it easier to grok.

What I found out was that data-planes is dependent on legacy-data-planes and I think it should be the other way around.

For example, we can't just remove the legacy-data-planes module once its no longer needed because data-planes depends on it here

kuma-gui/packages/kuma-gui/src/app/data-planes/routes.ts

Line 85 in 79ad517

component: () => import('@/app/legacy-data-planes/views/RootView.vue'),

If we remove legacy-data-planes then data-planes breaks.

Its also a lot clearer to figure out what is going on if you can rule the legacy-data-planes folder out entirely.

---

Apart from this I moved the top most routes routing config to the top of the file so it right there when you open the file instead of "below the fold"

[schogges]

It took me a while to figure out what the routing structure was here and I moved it a little to make it easier to grok.

What I found out was that data-planes is dependent on legacy-data-planes and I think it should be the other way around.

Hmm 🤔 I think the dependencies are correct. We are going to remove legacy-data-planes at some point 🤞 and therefore it'd be weird to me to have the dependency the other way around. We have data-planes as the main thing and a temporary dependency to the legacy stuff. Once that is removed from the backend we can cut this dependency off and leave everything else more or less as is.

For example, we can't just remove the legacy-data-planes module once its no longer needed because data-planes depends on it here

kuma-gui/packages/kuma-gui/src/app/data-planes/routes.ts

Line 85 in 79ad517

component: () => import('@/app/legacy-data-planes/views/RootView.vue'),

If we remove legacy-data-planes then data-planes breaks.

Its also a lot clearer to figure out what is going on if you can rule the legacy-data-planes folder out entirely.

For sure we can't "just remove" legacy-data-planes without removing the references too. But every file that can/should/will be removed is kept in one place.

Apart from this I moved the top most routes routing config to the top of the file so it right there when you open the file instead of "below the fold"

No strong opinion on this 👍

[johncowen]

I'm not super strong either tbf 😆 , although let me put an argument forward!

Imagine if we were to feature flag legacy-data-planes and only load the legacy-data-planes module when the flag was on i.e. we want to guarantee no code from it is used/loaded when the flag is off.

Then of course we want to be able to turn the feature flag on and off depending on something (ok, granted we don't need to do this but bear with me!)

If we had it like it was previous to this PR, if we turned off legacy-data-planes in one environment and still have it on in another, then data-planes would be broken in one environment but not the other because data-planes depends on code we are feature flagging.

Whereas with this PR, the relationship is inverted, legacy-data-planes depends on data-planes instead. We can turn legacy-data-planes on/off and it doesn't affect anything but legacy-data-planes.

Granted once we no longer need/have legacy-data-planes at all, we can delete the code entirely, remove the feature flag but then we still might go in and remove the code in data-planes that allows it to switch between the two based on the old feature flag - but you'd still have to do this anyway whichever way around you did it. i.e. with the old way when you delete legacy-data-planes data-planes is broken because it depends on legacy-data-planes, so you have to go in and change things.

Ideally of course we would be able to do these sorts of things from The Outside (which is what we do with our "boot-time" service container) then you don't need to have code anywhere on The Inside that deals with these sorts of usecases. (obvs I get we can't do that here because we are post-boot)

I do thing the difference between both options is very small, but given the above and the fact that it took me a while to figure out where some props.data was coming from (it was in RootView in the legacy module which I didn't expect), I do think I prefer this option.

Anyway, as I said not a strong opinion either, but there's my reasoning.

---

This needs a rebase, gonna sort that and ping you for another review, lmk on the above, also happy to approve/merge and discuss further. Also fine to have a stronger opinion and I'd be fine to put it back if so 👍