blocks: how to handle 'undocked' blocks
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- javascript
- Domain
- frontend
Research direction
Start by reading the discussion in this issue, especially the examples of undocked blocks, then review issue #42 and the referenced PXT issue #849. The issue needs an agreed behavior for undocked blocks before implementation can begin; completion criteria are not defined here.
Written by the indexing model from the issue text.
Description
(this is a complex one that I think needs some discussion - opening this issue as a place for that)
At the moment in blocks, as far as I can see, any block on the canvas will cause code to be generated and likely run. There aren't 'hats' or 'events', not even an 'on start' one.
This can cause a few possible issues.
For one, it's fundamentally different to scratch

In this case, the 'hmm' will never happen.
The difference is not in itself a reason to change, but In the past we've seen kids use 'undocking' blocks as a way to 'comment them out' (IE you build a complex set of blocks and then 'undock' them in order to stop them running. This is one good reason to think about how things work.
(it's also different from PXT, too)
Secondly, it can create some confusing things on canvas if your project has grown and then shrunk again.
For example, someone who knows how to code will easily spot the issue here:

...but for someone who is only focused on the blocks this could be really confusing. This is a slightly artificial example, but I think the problem in general is real, especially given the lack of clear notification that things are not currently visible, etc. (see in part #42 )
Note that PXT removed 'hats' early on in development and decided to add them back. There's a good discussion about that here:
https://github.com/Microsoft/pxt/issues/849
- Dominant language
- JavaScript
- Stars
- 201
- Forks
- 126
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bbcmicrobit/PythonEditor
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
bbcmicrobit/PythonEditor#406 ·
-
U Open
Difficulty 5/5 Over a week Newbie friendliness 1/100
bbcmicrobit/PythonEditor#405 ·
-
Difficulty 5/5 Over a week Newbie friendliness 10/100
bbcmicrobit/PythonEditor#391 · 2 comments · 6 reactions ·
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
bbcmicrobit/PythonEditor#375 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
bbcmicrobit/PythonEditor#367 ·
All issues in bbcmicrobit/PythonEditor
Similar issues
-
ai-observability bug team/ai-observability
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
AllTheMods/ATM-10-L#19 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
SignalK/n2k-signalk#345 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
JuliaPluto/PlutoPlotly.jl#72 ·