57 lines
3.5 KiB
Markdown
57 lines
3.5 KiB
Markdown
# 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.
|