You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Avoid having two really long functions - fetch and actionInput - where all the logic is happening. It would be easier to read and understand if, within those functions, we had some logic broken out into smaller functions with names like setUpValuesForInstall or setUpValuesForUpgrade.
Avoid removing global values just to re-add them again. Currently we have two functions - removeGlobalValuesFrom and addGlobalValuesTo. Each does the opposite. removeGlobalValuesFrom removes each value from global values if it is equal to what is the current and correct value. Then addGlobalValuesTo calls setIfNotSet to re-add each value again. It would be better to use the lodash merge function (which is already used elsewhere in the file) to handle all the global values in actionInput at the very end of the workflow. This would make it harder to introduce some error when we change or add a global value, which we had to do for project monitoring.
Convert it to typescript. While documenting the component I had to write out which values were strings, and what keys were in certain returned objects. It would be cleaner if that was in Typescript.
The text was updated successfully, but these errors were encountered:
This issue is a follow-up to #6068. While I was documenting the logic for how Rancher handles Helm chart app values, I saw some opportunities to refactor https://github.com/rancher/dashboard/blob/release-2.6.5/pages/c/_cluster/apps/charts/install.vue.
Here are the three changes I would make:
fetch
andactionInput
- where all the logic is happening. It would be easier to read and understand if, within those functions, we had some logic broken out into smaller functions with names likesetUpValuesForInstall
orsetUpValuesForUpgrade
.setIfNotSet
to re-add each value again. It would be better to use the lodashmerge
function (which is already used elsewhere in the file) to handle all the global values inactionInput
at the very end of the workflow. This would make it harder to introduce some error when we change or add a global value, which we had to do for project monitoring.The text was updated successfully, but these errors were encountered: