Refactor/variables-redux

[PaulFarault]

Which issue(s) this PR fixes

Fixes #138

Additional comments

Handle service and component variables through Redux:

• Initialize Redux with 3 slices:
  • config, to handle user config (read from the config.json in dev mode, and fetched from /config when exported)
  • variables, to handle variables fetched from the server with a loading state.
  • userInput, to hold variables changed by an user for a given service (and its components). Thought, I'm not sure that Redux is the good place to store those infos.
• TODO: Actualize sub-part of the slice when navigating through services and components. For now, variables are only fetched all at once when loading the app.
• TODO: Store the logs in a log slice.

This PR allows:

• To use Redux to handle the global state instead of using useContext/useReducer. Redux is well documented and should be easier to maintain.
• To fix most of the bug linked to component and service switches.
• To improve performances, as variables as store since the first API call.

Agreements

• I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004.
• I hereby agree to grant TOSIT a copyright license to use my contributions.

[mdrutel]

Hi,
I have 2 comments, I don't know if they are bound to this issue ^^'

1. When you first go to a Service page (eg. : http://localhost:3000/services/hive), when you click on "Validate" without doing anything else, a notification appears ("Variables changed"), but no request is sent to the server.

2. When you modify a variable and click on "Validate" :

• first click : the notification "Variables changed" appears
• second click and next : 2 notifications appears : "Variables changed" and "validating these changes would produce no difference"

[PaulFarault]

Thanks for your review, I'll have a look at it!

[PaulFarault]

You were right, I added both:

• a toast / early return statement if nothing have been modified
• a cleanup of the state when the request succeeded

Would be even better after #131

[PaulFarault]

One more thing to fix : When editing a value and then undoing the changes (the store holds the variable already on the server), an error is thrown in addition to this toast :

validating these changes would produce no difference

[PaulFarault]

Done, also added a reset of the user inputs when switching from a service to another which was causing a bug.

---

Thought, I'm not sure that Redux is the good place to store those infos.

This kinda confirms what I thought. Ideally, we should compare the inputted values to the server ones to avoid the "validating these changes would produce no difference" error. However, 2 slices cannot be mixed (variables and userInput in this case).

The solution would be to store in a context local to the service the variables modified for a service and its components. Then, possibly persist this context in the global store (or local storage) if we want to keep the user's uncommitted modifications in memory.

I'm gonna try to roll back to a local context for this feature but this time using a reducer instead of a simple state (keeping the same logic as the slice).

[mdrutel]

Hi,

I have other comments ^^'

I suppose that the type of the variable is checked before validation.

• There's a difference of behavior between the first and the second modification in case of an error : eg. :

  • "hdfs"zz and click on "Validate" => information with "No variables to change"
  • rollback and click on "Validate" => error with "validating these changes would produce no difference"
  • "hdfs"zz and click on "Validate" => error with "validating these changes would produce no difference"

• With the boolean type, is there a difference between true and "true" ?
  in the YAML file, the result is :

  • true => true
  • "true" => 'true'

[mehdibn]

Approved from a fonctional point of view

[mdrutel]

Approved from a fonctional point of view

[PaulFarault]

@mdrutel

There's a difference of behavior between the first and the second modification in case of an error

The behavior that you describe is a bit odd but is not a big error. In fact, variables that are similar to the one that are one the server shouldn't even be sent. I'll open an issue to improve this later. (#164)

With the boolean type, is there a difference between true and "true" ?

Some Hadoop services ask for boolean, and other for string. It's not really an UI issue. What we could do to improve the ux is:

• Display the type of each variable in an explicit way. (Variable display styles #130)
• Use the json schema to show descriptions for those variables.