React Switch Component with TypeScript

This challenge asks you to build a reusable Switch component in React using TypeScript. A switch component provides a visual toggle between two states (on/off, true/false, etc.) and allows users to easily change the current state. This is a common UI element used in various applications for settings, preferences, and feature toggles.

Problem Description

You need to implement a Switch component that accepts the following props:

• isOn: A boolean value indicating the initial state of the switch (defaults to false).
• onChange: A function that is called when the switch is toggled. This function should receive the new boolean value (true or false) as an argument.
• id: A string representing the unique identifier for the switch (optional, but recommended for accessibility).
• ariaLabel: A string providing an accessible label for the switch (optional, but recommended for accessibility).

The component should render a visually appealing switch that can be toggled by the user. When toggled, the onChange function should be called with the new state. The component should also update its internal state to reflect the current toggle state. The visual representation should clearly indicate the current state (e.g., different colors or icons for on/off).

Key Requirements:

• The component must be written in TypeScript.
• The component must handle the isOn prop correctly, initializing the switch to the specified state.
• The component must call the onChange prop function with the correct new state when toggled.
• The component should have a visually clear indication of the current state.
• The component should be accessible (consider aria-label and id props).
• The component should be reusable and accept the specified props.

Expected Behavior:

• When the component initially renders, the switch should reflect the value of the isOn prop.
• Clicking the switch should toggle its state (on to off, off to on).
• After each toggle, the onChange function should be called with the new state.
• The visual representation of the switch should change to reflect the new state.

Edge Cases to Consider:

• onChange prop is not provided (handle gracefully, perhaps by logging a warning).
• isOn prop is initially true or false.
• The component is re-rendered with a different isOn prop value.

Examples

Example 1:

Input: <Switch isOn={true} onChange={(newState) => console.log(newState)} id="darkModeToggle" ariaLabel="Toggle Dark Mode"/>
Output: A switch component visually indicating "on" state, and when clicked, logs "false" to the console.
Explanation: The component initializes to the "on" state and calls the provided `onChange` function with the opposite boolean value upon click.

Example 2:

Input: <Switch onChange={(newState) => alert(newState)} />
Output: A switch component initially in the "off" state. When clicked, it toggles to "on" and displays an alert box with the value "true".
Explanation: The component defaults to "off" and calls the `onChange` function with the new state upon click.

Example 3: (Edge Case)

Input: <Switch isOn={false} onChange={() => {}} />
Output: A switch component initially in the "off" state. Clicking the switch does nothing (because the onChange function is empty).
Explanation: The component handles the case where the `onChange` function is empty without errors.

Constraints

• The component should be implemented as a functional component using React Hooks.
• The component should be reasonably performant (avoid unnecessary re-renders).
• The visual styling of the switch is left to your discretion, but it should be clear and functional. You can use CSS or a CSS-in-JS library.
• The component should be self-contained and not rely on external state management libraries (like Redux or Context) unless explicitly allowed.

Notes

• Consider using the useState hook to manage the internal state of the switch.
• Think about how to handle accessibility best practices when implementing the switch.
• Focus on creating a clean, reusable, and well-documented component.
• You can use any CSS styling approach you prefer.
• The visual appearance of the switch is less important than its functionality and adherence to the requirements.