[TASK](ui): Migrate Switch component to TypeScript

[barsukov]

Task Description

We need to convert Switch and all related components from @cloudoperators/juno-ui-components to TypeScript

List of potential dependencies

• Check files that used with Switch, SwitchRow

Sub-tasks

• [x] change the name to .tsx of all related components
• [x] Change the stories to .tsx and all related componetns
• [x] fix all errors related to npm run typecheck
• [x] Transfer all related tests to vitests from jest
• [x] Check if npm run build is working and prove the working parts in storybook or example app
• [x] Check that npm run lint is working correctly and fix all tslint errors

Related Issues

• 168

Additional Context Please check this online codemode editor to change the PropTypes to a proper Ts interfaces

https://github.com/mskelton/ratchet Online editor: https://ratchet.mskelton.dev/

We need to be pretty concious about migration to ts cause it could create a potential breaking changes. Also if there will be too much changes at once maybe consider to split up the task again. Also some dependencies could be hidden and only discovered while executing the migration, could also lead to potential reconsidering the order of task execution.

[guoda-puidokaite]

Bug Found 🐞

Issue: Component can be valid and invalid at the same time, displaying icons for both states and applying the valid state to the switch outline. Explanation: See screenshot. Because there's two props called valid and invalid, the below bug is possible.

Fix: We should combine valid and invalid into a single state to prevent redundancy and therefore, this bug. UX Improvements: See https://github.com/cloudoperators/juno/issues/255#issuecomment-2456596321

CC: @edda

[guoda-puidokaite]

Future Improvements 🚀

• Required Indicator: A required indicator ensures that users complete all necessary fields before submission. I wonder if it make sense for a toggle to have a required icon if it’s always in a valid on/off state and no submission is required? I’d recommend having a required icon + error/info message stating “Field is required” (or similar) only when the user hasn’t filled the field, but it’s necessary to proceed. This should disappear once the condition is fulfilled. Otherwise, the icon isn’t sufficient on its own. At the very least, let's add a message to explain the required icon.
• Introduce Variants: To keep consistent with other components e.g. Message... Introduce variants containing helptext, errortext, successtext, valid and invalid props to reduce redundancy, prevent bugs as here, have more control in our component and make the component user experience better too.
• Success/Error Indicators:
  • To improve UX, we should accompany all icons with a message (same as above).
  • Do we need a tick/cross icon + green/red switch outline to indicate the two states? Could we improve UX here and ensure state consistency across all components?
• Prop Naming: Could we make helptext, errortext and successtext camel case, aligning with other props and JS/TS naming conventions?

See screenshot:

[edda]

Bug Found 🐞

Issue: Component can be valid and invalid at the same time, displaying icons for both states and applying the valid state to the switch outline. Explanation: See screenshot. Because there's two props called valid and invalid, the below bug is possible. Fix: We should combine valid and invalid into a single state to prevent redundancy and therefore, this bug. UX Improvements: See #255 (comment)

CC: @edda

It was a conscious decision to separate the valid/invalid props. The reason is that it is not a boolean valid/invalid. invalid is for form validations (e.g. a mandatory field wasn't filled, a field was filled in the wrong format, etc.). The valid prop is not the inverse of invalid, i.e. if something ceases to be invalid (because the user corrected their input) you're not meant to switch to the valid state, instead you simply deactivate the invalid state. The valid state is only meant to be used for very specific validations like e.g. a password field where you choose a new password and it has complex password rules. In that case you can use the valid state to show the user that what they entered fullfills the rules. However the valid state should not be used for everything that is valid in a form, because this would apply to almost anything, so you would have green borders and checkmarks on all the form elements and then it's better not to specifically highlight valid state to reduce visual clutter. This will also be explained in our design document.

[guoda-puidokaite]

Hey, @edda. The main issue stated was about the valid and invalid states being applied at the same time. The latter was just a suggestion, thanks for the explanation. Do you think the stated issue is indeed a bug or expected?

[edda]

@guoda-puidokaite essentially it's more a matter of trusting people to use it correctly. We could think about changing it in such a way that if both are true, only invalid is respected. But we'll have to do this change for all form components that have the invalid and valid states then. So I'd say, add it to the collection epic for possible future improvements :D

[guoda-puidokaite]

Thanks, @edda. I added some possible improvement suggestions from my side here.