Create Notebook / Community Block Tie

[ehynd]

Is there an existing issue for this?

• I confirm that I have not found an existing or similar issue.

Description

Right now, our community block flow is reusable UI blocks that get saved into the database. However, we want reusable components in general, not just reusable UI components.

The goal is to make a reusable form. This is just for POC. There will be a singular notebook dependency tied into the UI.

Relevant Feature or Code

Possible Implementation Strategy

Component Definition:

Dependency Resolution Workflow:

Possible Steps:
Saving Components -

1. Dependency Traversal

• Scan all blocks' data attributes for {{variable}}
  patterns
  -Parse event listeners for notebook/cell references
  Stop at direct dependencies ie (don't traverse notebook's dependencies)

2. Conflict Prevention

• Prefix variables: comp_123_var_a instead of var_a
• Namespace notebooks: comp_123_notebook_1

Loading Components:

1. Conflict Resolution

2. Template Application

• Replace all {{var}} references in blocks using mapping table
• Update event listeners with new notebook/cell IDs
• Inject "Community Source" tag into notebook metadata

Requirements (what)

No response

[johbaxter]

[Paulson-Robert]

🧩 Current Progress Update

✅ Accomplished:
Drag-and-Drop Implementation for Community Block

On dropping a community block, the associated notebook and queries are now successfully generated.

For handling multiple drops of the same block:

Implemented a query scanner function that assigns a unique queryId for each instance.

The respective queryId is updated correctly within the dropped block.

⚠️ Current Challenge:
Variable Association Tracking Issue

While applying a similar flow for variables, I'm facing a challenge in keeping track of the "to" property.

The "to" property is supposed to point to the block ID the variable is associated with.

However, on each drop of a community block, all related blocks are regenerated with new unique IDs.

This causes a loss of linkage between the variable and its target block.

💡 Brainstorming In Progress:
Exploring possible solutions to re-map or retain the correct association between variables and their intended blocks, even after ID regeneration.

[Paulson-Robert]

✅ Proposed Solution (v1) — Tracking the to Property

1. Capture source IDs on community block creation

   • When a block is saved as a Community Block, the original id of each item in the block JSON is stored.

2. Add referenceId on community block reuse

   • On drag-and-drop, the community block goes through the normal process of query and variable creation.
   • During this, new IDs are generated and assigned to each item.
   • A referenceId field is added to each new item to retain the original ID for mapping purposes.

3. Remap the to property after creation

   • After variables are created, the logic iterates through the new block JSON.
   • Any to fields pointing to old block IDs are replaced by matching the referenceId with the newly generated ID.

🎥 Video Demo (Happy Path - v1)

SEMOSS.2.webm

---

🔁 Next Steps (v2)

• The initial version works end-to-end (see video above).
• The next iteration will focus on:
  • Code clean-up and optimization

---

✅ Test Cases to Cover

1. Variable Mapping

   • Variables used inside the Community Block should be:
     • Auto-created
     • Mapped correctly to their respective to fields

2. Query Mapping

   • Queries inside the Community Block should be:
     • Duplicated properly with new IDs
     • Reconnected to the correct variables/blocks via referenceId mapping

---

Please share feedback or edge cases.

[Paulson-Robert]

🧪 Bug: Dependent cell variable not updating in block JSON for repeated community block drops

Context:
During unit testing, we observed an issue when dropping the same community block multiple times into the designer.

---

Issue:
If the block contains a dependent cell that references a variable, that variable is not getting updated in the blockJSON on subsequent drops. Instead, it retains the original variable name from the first inserted instance.

---

Expected Behavior:
Each time a community block is added, any dependent variable inside it should be updated with the newly generated variable specific to that instance — and reflected correctly in the blockJSON.

Actual Behavior:
The variable inside the dependent cell remains unchanged, leading to incorrect references and potential runtime errors or unexpected behavior.

---

🛠️ Next Step:
I'll be debugging this to trace where the variable assignment in blockJSON is failing to propagate during multiple insertions.