anshk/builder-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: task2 notes

Browse Source
This commit is contained in:
anshk 2026-04-07 11:12:52 +05:30
parent 0fb22a1c6e
commit c49060e09a
3 changed files with 134 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
Week-2/Task-2/ProductLens.md
View File

@ -1,5 +1,12 @@
## 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?
- Guided product stories where objects appear/disappear across steps.
- Feature comparison scenes with predefined arrangements.
- Presentation flows where one click changes scene composition and framing.
- Does Thob feel strong enough for this use case?
- Partial. The pattern is possible by combining object visibility states and Perspective Camera positions, but button-triggered updates are not reliably synchronized.
- What would improve the experience?
- One button should update all linked properties simultaneously, or fast enough that transitions feel instant.
- Better multi-target binding UX for visibility, transforms, and camera props.
- Clearer feedback/debugging for whether each bound prop was successfully updated.

63
Week-2/Task-2/TaskNotes.md
View File

@ -1,60 +1,89 @@
# Task: [Feature Name]
# Task: Scene State Switching (Visibility + Transform Presets)
## Objective
What is the feature trying to do?
Switch between predefined scene states where each state controls object visibility, object transforms, and scene framing behavior.
## Vanilla three.js
-Possible: Yes / Partial / No
-Possible: Yes
-Notes:
- Uses a `states` map with three scene presets (`state1`, `state2`, `state3`).
- Each state defines object `position`, `rotation`, and `visible` values.
- Buttons and keyboard shortcuts apply state changes, and transforms are smoothed with lerp.
-Key concepts:
-Complexity: Easy / Medium / Hard
- State configuration object
- Visibility toggling per object
- Transform interpolation
- UI-triggered state transitions
-Complexity: Medium
## R3F
-Possible: Yes / Partial / No
-Possible: Yes
-Notes:
- Uses React state (`stateKey`) to drive active scene state.
- `SCENE_STATES` config mirrors vanilla behavior in a declarative structure.
- `useEffect` updates visibility/targets and `useFrame` handles smooth interpolation.
-What R3F abstracted:
-Complexity: Easy / Medium / Hard
- Render-loop management via `useFrame`
- State-driven scene updates through React
- Cleaner component organization for scene objects
-Complexity: Medium
## Thob Page Builder
-Possible: Yes / Partial / No
-Possible: Partial
-Notes:
- We can make things like this by creating combinations of object visibility and Perspective Camera position, but the button issue persists.
- We should be able to click the button and it all should be simultaneously or fast enough to not notice.
- Current button flow is not reliable enough for multi-property state switching.
-Builder steps:
-Complexity: Easy / Medium / Hard
- Create scene objects and define visibility combinations.
- Set Perspective Camera positions for each target state.
- Add state buttons.
- Try binding each button to all required prop changes (visibility + transforms + camera).
-Complexity: Hard
## Comparison Summary
-Possible in all 3? Yes / Partial / No
-Possible in all 3? Partial
-Main differences:
- Vanilla and R3F both support clean, predictable state switching.
- Thob can represent the same state idea, but synchronized multi-prop button updates are not smooth/reliable yet.
-Where Thob is better:
- Fast visual setup of objects, visibility states, and camera values.
-Where Thob is weaker:
- Button-driven multi-target updates are difficult to make feel atomic.
-What feels awkward or unclear:
- Mapping one button to many coordinated prop updates without visible delay or missed updates.
## Limitation Type (if any)
-[ ] Editor UX limitation
-[x] Editor UX limitation
-[ ] Runtime limitation
-[ ] Schema / data model limitation
-[ ] Component limitation
-[ ] Event system limitation
-[x] Event system limitation
-[ ] Asset pipeline limitation
-[ ] Unknown / needs investigation
## Workaround
-Is there a workaround?
- Partial workaround.
-If yes, what is it?
- Manually set visibility and camera values in sequence.
- Use simpler, fewer state transitions to reduce button binding complexity.
## Suggested Improvement
-What should improve in Thob?
- Allow one button to trigger bundled multi-component updates in one action.
- Ensure updates happen simultaneously (or visually instant) for all linked props.
- Improve binding UX so multi-target mappings are easy to build and verify.
-Is it:
- editor
-runtime
-component
- UX
-schema/data
- component
## Difficulty Estimate
-Easy / Medium / Hard
-Medium
## Business Value
-Low / Medium / High
-High
## Recommendation
Should Thob support this better? Why?
Yes, Thob should support this better because state-based visibility and framing transitions are common in demos and guided presentations. Reliable one-click synchronized updates would significantly improve real project usability.

77
Week-2/Task-2/builder/BuilderNotes.md
View File

@ -0,0 +1,77 @@
# Builder Notes (Thob) — Task 2: Scene State Switching
## Thob Observations from Task Notes
- **Possible:** Partial
- **Implementation used:** Combinations of object visibility states and Perspective Camera positions, with button-based switching attempts.
- **What worked as expected:**
- Visibility states can be configured for multiple objects.
- Camera position presets can be prepared for different scene views.
- Base scene composition is quick to assemble in the editor.
- **Main limitation observed:**
- One button updating multiple targets (visibility + transforms + camera) is not consistently reliable.
- Updates should happen simultaneously (or fast enough to feel instant), but current behavior can feel staggered/inconsistent.
- Button binding flow remains hard to reason about for multi-prop state orchestration.
- **Builder flow used:**
1. Create scene objects and set initial visibility/transform states.
2. Add Perspective Camera and set target positions per scene state.
3. Add state buttons in UI.
4. Attempt to bind each button to all required prop updates.
5. Validate whether transitions are synchronized and repeatable.
- **Complexity:** Hard
- **Main limitation signals:** Editor UX + Event system + Runtime stability concerns.
- **Workaround status:** Partial workaround only (manual or simplified transitions; full one-click synchronized switching is not dependable yet).
## Console Warnings/Errors Seen (Deduplicated) and Probable Meaning
### warn: `Found both blacklist and siteRules — using siteRules`
- **Type:** Configuration precedence warning.
- **Probable meaning:** Multiple rule sets are available and runtime is choosing one path (`siteRules`).
- **Impact:** Usually low, but indicates overlapping configuration paths.
### warn: `... changing from uncontrolled to controlled` and `RadioGroup is changing from uncontrolled to controlled`
- **Type:** React state-management warning.
- **Probable meaning:** UI controls start with unstable values and later switch to controlled mode.
- **Impact:** Property panel/control behavior can become inconsistent during binding setup.
### warn: `Permissions-Policy header: Unrecognized feature: 'browsing-topics'`
- **Type:** Browser/header compatibility warning.
- **Probable meaning:** Response headers include unsupported policy directives for current browser.
- **Impact:** Low direct impact on scene logic; mostly environment noise.
### warn: `Unchecked runtime.lastError: The message port closed before a response was received`
- **Type:** Browser runtime/extension messaging warning.
- **Probable meaning:** A message channel closed before callback completion.
- **Impact:** Usually non-fatal, but adds noise and can complicate debugging.
### warn: `GetBindingData<id> method already registered` (repeated)
- **Type:** Duplicate registration warning.
- **Probable meaning:** Binding handlers are being registered repeatedly across rerenders/remounts.
- **Impact:** High relevance for this task; can cause duplicate triggers and unreliable button-driven state updates.
### warn: `update-static-component-prop method already registered`
- **Type:** Duplicate update pipeline warning.
- **Probable meaning:** Static prop update handler is attached more than once.
- **Impact:** Can produce repeated writes and non-atomic multi-prop transitions.
### warn: `resetPOI method already registered`
- **Type:** Duplicate command registration warning.
- **Probable meaning:** Camera/POI reset command is mounted multiple times.
- **Impact:** Camera behavior may drift or feel inconsistent during state switching.
### error: `Failed to load resource: 404`
- **Type:** Network/resource error.
- **Probable meaning:** Missing/stale project asset or endpoint.
- **Impact:** Can partially break expected editor/preview behavior.
### error: `THREE.WebGLRenderer: Context Lost`
- **Type:** Graphics runtime error.
- **Probable meaning:** WebGL context dropped due to resource pressure, remount loops, or browser/GPU reset.
- **Impact:** Preview instability can invalidate transition testing.
## Overall Read
- Task 2 concept is achievable in thob at a basic level: visibility and camera state combinations can be authored.
- The key product gap is synchronized execution: one button should apply all linked updates simultaneously, but current binding behavior is not reliably atomic.
- Recurring duplicate-registration warnings strongly match the interaction issues seen during multi-prop button setup.
- Improving binding lifecycle stability and one-click bundled updates should be the highest priority for this task pattern.