docs: thob task 3 report (visibility switcher)

This commit is contained in:
divyap 2026-04-13 16:34:29 +05:30
parent 0cc05e470e
commit 380b9982ca

View File

@ -1,66 +1,56 @@
# Task: UI-Controlled Product Option (Configurator Pattern)
# Week 2 Task 3 - Product Option Switcher
## Objective
Create a simple product option UI that changes the 3D models appearance (Black, Silver, Gold buttons).
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 / Partial / No
-Notes:
-Key concepts:
-Complexity: Easy / Medium / Hard
- **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 / Partial / No
-Notes:
-What R3F abstracted:
-Complexity: Easy / Medium / Hard
- **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 / Partial / No
-Notes:
-Builder steps:
-Complexity: Easy / Medium / Hard
- **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 / Partial / No
-Main differences:
-Where Thob is better:
-Where Thob is weaker:
-What feels awkward or unclear:
- **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
-[ ] Runtime limitation
-[ ] Schema / data model limitation
-[ ] Component limitation
-[ ] Event system limitation
-[ ] Asset pipeline limitation
-[ ] Unknown / needs investigation
- [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?
-If yes, what is it?
- **Is there a workaround?**: Not required for functionality; manual trial-and-error was used to find the correct visibility binding syntax.
## Suggested Improvement
-What should improve in Thob?
-Is it:
-editor
-runtime
-component
-UX
-schema/data
## Difficulty Estimate
-Easy / Medium / Hard
- **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
-Low / Medium / High
- **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 / Partial / No
- What kind of customer use case does this support?
- Does Thob feel strong enough for this use case?
- What would improve the experience?
- **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
Should Thob support this better? Why?.
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.