Nick Fox

This is blocked by #6360

It doesn't matter to me one way or another but why prefer the arrow function over a regular function? Seems like: This is a function ``` function doSomething() { }...

Sure the issue is here inside of the `Grafana()` call (and everywhere else this happens): https://github.com/kiali/kiali/blob/9cb961f10a7e7c9ce98765b4094402ee95abaa7b/tests/integration/utils/kiali/kiali_client.go#L605-L616 Until we check the status code, we can't safely unmarshal into `status := new(models.GrafanaInfo)`...

The kiali client methods can now use this method: https://github.com/kiali/kiali/blob/470b68b0909efc0e1adf75b1675efc20b39f1f42/tests/integration/utils/kiali/kiali_client.go#L647-L663 which will check the status code before unmarshaling. We just need to update the kiali client methods to use this...

@PrinsonF77 I would say just update the methods that _don't_ return a status code to use that `getRequestAndUnmarshalInto` function and leave the methods that already return a status code as...

> I think this would allow for most of the kiali client methods to be rewritten in this way which reduces the redundancy and helps with returning better error messages....

Some investigation was done awhile back and that PR can be used as a reference: https://github.com/kiali/kiali-ui/pull/2267. @ferhoyos are there any potential risks wrt OSSMC?

> No, I don't think so. Redux-toolkit does not necessarily increase the performance of the application. Beyond just making it easier to develop on the frontend, I'd actually argue that...

> Here we have two different things: Agreed these are separate things and adopting rtk won't increase performance but it should make it easier to use/re-use redux across the app...

> I guess it triggers the question if we want to change the way we deal with Kubernetes vs Istio. > I mean, same happen to other resources, that may...