docs: thob task 3 report (visibility switcher)

Week-2/Task-3/report.md

@@ -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 model’s 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
+- **Possible**: Yes
--Notes:
+- **Notes**: Requires managing multiple mesh instances and updating their `visible` property based on DOM events. 
--Key concepts:
+- **Key concepts**: Mesh Visibility, Conditional Logic, Event Delegation.
--Complexity: Easy / Medium / Hard
+- **Complexity**: Easy (Standard object property mutation).
 
 ## R3F
--Possible: Yes / Partial / No
+- **Possible**: Yes
--Notes:
+- **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:
+- **What R3F abstracted**: Mounting/unmounting lifecycle and state-to-visibility mapping.
--Complexity: Easy / Medium / Hard
+- **Complexity**: Easy.
 
 ## Thob Page Builder
--Possible: Yes / Partial / No
+- **Possible**: Yes
--Notes:
+- **Notes**: Successfully implemented by binding the `Visible` property of different mesh nodes to a `RadioGroup`'s selected state.
--Builder steps:
+- **Builder steps**: Create Mesh A & B -> Set up RadioGroup loop -> Link selection ID to the "Visible" toggle in the Properties panel.
--Complexity: Easy / Medium / Hard
+- **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
+- **Possible in all 3?**: Yes
--Main differences:
+- **Main differences**: Vanilla/Thob use property toggling (hide/show); R3F uses conditional rendering (mount/unmount).
--Where Thob is better:
+- **Where Thob is better**: "Logic Toggling" is purely visual—no need to write an `if-else` block in code.
--Where Thob is weaker:
+- **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:
+- **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
+- [x] Editor UX limitation (Hierarchy clutter)
--[ ] Runtime limitation
+- [x] Documentation/Discovery limitation (Proprietary syntax)
--[ ] Schema / data model limitation
+- [x] Runtime limitation (Unexpected Application Error / Cylinder crash)
--[ ] Component limitation
+- [x] Schema / data model limitation (Repeated binding warnings)
--[ ] Event system limitation
+- [ ] Asset pipeline limitation
--[ ] Asset pipeline limitation
--[ ] Unknown / needs investigation
 
 ## Workaround
--Is there a workaround?
+- **Is there a workaround?**: Not required for functionality; manual trial-and-error was used to find the correct visibility binding syntax.
--If yes, what is it?
 
 ## Suggested Improvement
--What should improve in Thob?
+- **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).
--Is it:
+- **Secondary Optimization**: Standardize the data-binding system to prevent the `method already registered` warnings during visibility shifts.
-  -editor
+- **Is it**: Editor, UX, Docs.
-  -runtime
-  -component
-  -UX
-  -schema/data
-
-## Difficulty Estimate
--Easy / Medium / Hard
 
 ## 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
+- **Is this pattern useful for real customers?**: Yes.
-- What kind of customer use case does this support?
+- **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?
+- **Does Thob feel strong enough for this use case?**: Yes. The end-user transition is seamless.
-- What would improve the experience?
+- **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.