# Week 2 Task 3 - Product Option Switcher

## Objective
Implement a UI-driven geometric switcher that toggles the visibility of different objects (Cube/Sphere) to simulate product part selection.

## Vanilla three.js
- **Possible**: Yes
- **Notes**: Requires managing multiple mesh instances and updating their `visible` property based on DOM events. 
- **Key concepts**: Mesh Visibility, Conditional Logic, Event Delegation.
- **Complexity**: Easy (Standard object property mutation).

## R3F
- **Possible**: Yes
- **Notes**: Generally implemented using conditional rendering (e.g., `{selected === 'cube' && <Cube />}`). This is more performant as React only mounts/unmounts the 3D objects as needed.
- **What R3F abstracted**: Mounting/unmounting lifecycle and state-to-visibility mapping.
- **Complexity**: Easy.

## Thob Page Builder
- **Possible**: Yes
- **Notes**: Successfully implemented by binding the `Visible` property of different mesh nodes to a `RadioGroup`'s selected state.
- **Builder steps**: Create Mesh A & B -> Set up RadioGroup loop -> Link selection ID to the "Visible" toggle in the Properties panel.
- **Complexity**: Medium (Configuring visibility logic across multiple objects is more time-consuming than simple material swaps).

## Comparison Summary
- **Possible in all 3?**: Yes
- **Main differences**: Vanilla/Thob use property toggling (hide/show); R3F uses conditional rendering (mount/unmount).
- **Where Thob is better**: "Logic Toggling" is purely visual—no need to write an `if-else` block in code.
- **Where Thob is weaker**: The "Guessing Game" for syntax ($context) is even more prevalent here since you are mapping IDs to visibility states.
- **What feels awkward or unclear**: The layers panel becomes visually cluttered when managing multiple objects that share the same space but have different visibilities.

## Limitation Type (if any)
- [x] Editor UX limitation (Hierarchy clutter)
- [x] Documentation/Discovery limitation (Proprietary syntax)
- [x] Runtime limitation (Unexpected Application Error / Cylinder crash)
- [x] Schema / data model limitation (Repeated binding warnings)
- [ ] Asset pipeline limitation

## Workaround
- **Is there a workaround?**: Not required for functionality; manual trial-and-error was used to find the correct visibility binding syntax.

## Suggested Improvement
- **Primary Optimization**: Implement **Visual Logic Indicators** in the layers panel (e.g., an icon showing that an object's visibility is currently controlled by a specific UI element).
- **Secondary Optimization**: Standardize the data-binding system to prevent the `method already registered` warnings during visibility shifts.
- **Is it**: Editor, UX, Docs.

## Business Value
- **High**: Essential for configurators that have "Part Selection" (e.g., choosing different table legs or faucet styles).

## Product Lens
- **Is this pattern useful for real customers?**: Yes.
- **What kind of customer use case does this support?**: Architectural customizers (choosing window styles) and furniture configurators (choosing upholstery vs. leather bases).
- **Does Thob feel strong enough for this use case?**: Yes. The end-user transition is seamless.
- **What would improve the experience?**: Better transparency in the UI regarding which "Logic" is controlling which "Mesh."

## Recommendation
Thob's visibility system is reliable. The tool should focus on making the **Logic Links** visible in the editor so a user can immediately see "at a glance" which Radio Button is controlling which Mesh.