thob-capability-map/Week-2/Task-3/report.md

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)

• Editor UX limitation (Hierarchy clutter)
• Documentation/Discovery limitation (Proprietary syntax)
• Runtime limitation (Unexpected Application Error / Cylinder crash)
• 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.