✅ Deploy Preview for kuma-gui ready!

Name	Link
🔨 Latest commit	30cee64
🔍 Latest deploy log	https://app.netlify.com/sites/kuma-gui/deploys/67bee34258d28400083f63e0
😎 Deploy Preview	https://deploy-preview-3581--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 site configuration.

I think we are going to have to decide what to do about our "Global Format" values. Previous to this PR we had 2 possible values structured and yaml. Now, at least in some places we have 3 structured, yaml-universal and yaml-k8s.

Off the back of that I have a question, with some potential follow up questions/suggestions.

• I think the plan will be to have 3 options everywhere? Is that right do you think?

Separately, I think we will have to build the data interaction so if you don't have Kubernetes selected when landing on the page we don't make the ?format=kubernetes request, we only actually make it when you switch to kubernetes. If you do already have kubernetes selected when landing on a page, then of course its fine to make the ?format=kubernetes request when we land on the page.

I think we are going to have to decide what to do about our "Global Format" values. Previous to this PR we had 2 possible values structured and yaml. Now, at least in some places we have 3 structured, yaml-universal and yaml-k8s.

Of the back of that I have a question, with some potential follow up questions/suggestions.

• I think the plan will be to have 3 options everywhere? Is that right do you think?

Hmmm, good point 🤔 I think we will have more options everywhere. I think that would be beneficial for the UX, because as a kubernetes user I'm mainly/only interested in the k8s format. But during the time where we have to support yaml, yaml-universal and yaml-kubernetes (we don't know how long that'll be), it's probably better to have yaml and yaml-kubernetes only where yaml is both the format for yaml and yaml-universal. Wdyt?

Separately, I think we will have to build the data interaction so if you don't have Kubernetes selected when landing on the page we don't make the ?format=kubernetes request, we only actually make it when you switch to kubernetes. If you do already have kubernetes selected when landing on a page, then of course its fine to make the ?format=kubernetes request when we land on the page.

I was thinking about this and thought it'd be better to load this initially than loading it after selecting k8s 🤔 but I can move the DataLoader to wrap the k8s CodeBlock only.

I think we will have more options everywhere.

👍 cool

I think that would be beneficial for the UX, because as a kubernetes user I'm mainly/only interested in the k8s format.

Yeah this is where things can get weird. global could be on k8s, but a zone on that install could be universal or vice-versa. Or maybe I just want to see what universal looks like even though I'm totally on k8s.

Given the above maybe we should change the values to structured, universal, k8s? And we just implicitly know (because the default format for universal and k8s is YAML) that universal and k8s formats mean we are showing it in YAML for the specific software environment?

I think that would be beneficial for the UX, because as a kubernetes user I'm mainly/only interested in the k8s format.

Yeah this is where things can get weird. global could be on k8s, but a zone on that install could be universal or vice-versa. Or maybe I just want to see what universal looks like even though I'm totally on k8s.

Yeah, totally agree 👍

Given the above maybe we should change the values to structured, universal, k8s? And we just implicitly know (because the default format for universal and k8s is YAML) that universal and k8s formats mean we are showing it in YAML for the specific software environment?

Sounds good 👍 I'll change it, but would also like to ask wdyt we should do once we add JSON to the group? 🙂

The good thing is that in all the other places we currently have the flow of either show structured or the codeblock. So regardless if the user selects kubernetes or universal, in the other places the user will see the codeblock.

Sounds good 👍 I'll change it, but would also like to ask wdyt we should do once we add JSON to the group? 🙂

Hmm, depends, what will the content of the JSON be? I would guess we aren't doing "JSON Universal" and "JSON Kubernetes", but maybe we are?

Sounds good 👍 I'll change it, but would also like to ask wdyt we should do once we add JSON to the group? 🙂

Hmm, depends, what will the content of the JSON be? I would guess we aren't doing "JSON Universal" and "JSON Kubernetes", but maybe we are?

Not sure either, I guess we'll find out then 😄 I could imagine that we'd show everything yaml as json additionally, but not too sure.

I just realized another thing: we currently only show the select in case there is a spec. I think this should be changed now to only include the structured in case there is a spec, but in any case show the select with options Kubernetes and Universal.