From 380b9982ca86a2e47c20cbe66e0fd7f711d67182 Mon Sep 17 00:00:00 2001 From: divyap Date: Mon, 13 Apr 2026 16:34:29 +0530 Subject: [PATCH] docs: thob task 3 report (visibility switcher) --- Week-2/Task-3/report.md | 78 ++++++++++++++++++----------------------- 1 file changed, 34 insertions(+), 44 deletions(-) diff --git a/Week-2/Task-3/report.md b/Week-2/Task-3/report.md index f967c46..534fb7a 100644 --- a/Week-2/Task-3/report.md +++ b/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 --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' && }`). 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.