Fix requests

[SystemsPurge]

A collection of fixes and refactoring changes to make frontend run smoother with redux
Includes refactoring into functional components, and adjustment of some breaking changes that happened with the migration

[stv0g]

Thats pretty difficult or almost impossible to review for me :(

I just hope it does not break stuff..

I would welcome if we can return to better review practices in the VILLAS repos: Small PRs addressing one issue at a time.

[SystemsPurge]

@stv0g this is not meant to be the continous practice. It is unorganized due to being a collection of small fixes to exactly avoid a couple breaking changes.
The changes were reviewed when they were initially merged with the fix-requests branch from a fork.
As for the concern about the breaking change, i will shortly give you credentials to a test deployment if you want and you can test it out yourself...
As far as i noticed when i reviewed the PR from the fork to the branch, there were not any.
"Small PRs addressing one issue at a time." is definitely the plan, but keep in mind that there is a couple more things that need to be cleaned up first, and they might be spread across different contexts ( despite having to do with the same issue )

EDIT: if it is ABSOLUTELY an issue, i can squash some

[SystemsPurge]

@stv0g I squashed commits that have to do with one another.
Some commits contain branding stuff that one can ignore, as they are remnants of merge/rebase conflict resolution attempts and do not affect the actual application.
Also, over the last 4 months, we've had multiple deployments of the whole platform, i've been actively asking about issues and fixing them as they appear, those are the latest squashed commits into update button widget
I hope this now gives the confidence for a positive review

[stv0g]

Hi @SystemsPurge,

Sorry, I dont have the bandwidth at the moment to review these larger PRs.

@iripiri Do you have some resources to look at this (and the other refactoring/maintenance PRs in VILLASweb)?

[iripiri]

Hi @SystemsPurge and @Anyandsi,
the changes mostly look good to me!

I've tested the SLEW example in the villas.k8s deployment and had two issues:
a) Job execution fails because of hardcoded URL for results file!
b) there are two waiting symbols/GIFs running/visible which I don't understand
[c) name of component configuration is not visible as it was before, but this is negligible]

I was also confused with the file naming (js/jsx), it would be good to go through the files again and check whether this is really consistent.

[iripiri]

Shouldn't this also be .jsx?

[SystemsPurge]

We didn't want to make the changes any more unreadable in this review than they already are, if we go around changing all the filenames they would all be tagged and come up here. We are changing them gradually, most importantly in the dependency update PR

[iripiri]

This is a lot nicer than the old version 👍

[iripiri]

Why is the Files Dialog greyed out? Does it still need testing? What's the difference between this file and dashboard.jsx, can you add some explanatory comments in the code?

[SystemsPurge]

This one has always been grayed out. I restored it in some other branch and it seems to work. It should have the same functionality as the one in dashboard and will be restored accordingly in a next PR

[SystemsPurge]

@iripiri
a) See other comments
b) Try right clicking the circle and seeing if its actually a hanging IC status widget. That usually happens when the underlying IC component of a configuration used by a dashboard is changed, and the dashboard widgets are still attempting to query for the old IC.
c) I can look into it, but in the context of upgrading dependencies of the project, that specific json viewer is not going to be used anymore, or did you mean elsewhere?