Blockly: Add demo with +/- alternative mutator extensions for if/else, text_join, lists_create_empty, lists_repeat

[AnmAtAnm]

Problem statement

The block-based mutator UI is an advanced user feature that may not be appropriate for many of our users.

Proposed solution

Build alternative block mutator implementations for the following blocks:

• [ ] controls_if
• [ ] text_join
• [ ] lists_create_empty
• [ ] lists_repeat
• [ ] Function definitions (argument list)
• [ ] Add integration test that imports and exports the serialized blocks, and confirms results.

The alternative mutators should use field_images as + and - buttons to add and remove options. The serialize format should be identical to the existing mutators, allowing developers to switch mutators despite existing saved workspaces in the wild.

This may resolve #1747.

[AnmAtAnm]

Need to fix FieldImage click handlers (#1887) first.

[duzc2]

I have done something about this , with a working block.
it works good but looks ugly.
I need to know what to do to make it better for blockly and finish it.

[duzc2]

[duzc2]

any guides about how to use and how to implement it?
I think it's very important for some young-segment project,or somewhere want a easy to use dynamic blocks.

[duzc2]

maybe give some information about
block name ?
how a user choose the UI?

[AnmAtAnm]

@duzc2 Do you have a branch with the edits so far that we can investigate? There are a lot of unstated details in what we are looking for. Most importantly, the mutator save format must be the same as existing mutators.

I've added functions to the checklist above. Does your function definition mutator create and update variables names?

I expect function definitions will be the hardest one to reimplement in a compatible manner. I expected to start with the else clauses of controls_if.

[duzc2]

it's ok . i have a fork https://github.com/duzc2/blockly
I can implement it and compatible with the old ones.
but how a programmer choose the UI he want ?
I need some information about the usage.
should a programmer important another .js file ?
or add a argument to workspace / toolbox ?

[AnmAtAnm]

The developer would import another file. This file can assume the main file is already loaded, and just override the minimal set of block definitions, extensions, or function definitions. It is probably best to do this in a demo directory, instead of in the blocks directory, since this depends on the load order, and will not be a part of the blocks_compressed.js built file.

[BeksOmega]

I did some work on this this weekend and I now have a functioning prototype that works for all of the above blocks (except lists_repeat which doesn't have a mutator).

My questions are: Would you still like a demo of this? And if so, would you want it in this repo, or the samples repo?

You can view my changes here. It still needs cleanup, testing, and docs. I'll also try and get a demo you can play with working.

[Edit: [demo](http://bekawestberg.me/projects/alternative-mutators). Tell me if it breaks or you can't access it.]

[rachel-fenichel]

Sweet demo!

• Yes, we are still interested in a demo of this.
• It would go in the samples repo. Make a folder named blocks and put this in an alternative_mutators subfolder. We may rearrange as we go.
• What's the change with nonMixins?

[BeksOmega]

• Yes, we are still interested in a demo of this.

Sweet!

• It would go in the samples repo. Make a folder named blocks and put this in an alternative_mutators subfolder. We may rearrange as we go.

Sounds good

• What's the change with nonMixins?

This was a while ago, but looking back at the commit where it was added I believe it was because I wanted some mixins to be applied before my mutator was applied, so that the mutator could access those functions.

It turned out I refactored that away later, so I'll remove it from the demo, but it might be worth considering in the future.

---

It may be a bit before I get back to this, but I promise it's in my task management system so it won't be abandoned. -- Feel free to bug me about it if you see me being lazy though hehe

[BeksOmega]

Questions

Blocks Refactor

I was wondering how you would feel about refactoring some of the core blocks to make it easier to implement mutator UI changes.

My problem is that to change the Mutator UI you end up rewriting a lot of the core blocks' logic. Especially for list_create_with and procedure blocks which do not use the json definitions. I think that ideally you would only have to unregister and reregister one extension, which defines the mutator UI.

The plan would be to separate the mutationToDom and domToMutation methods from the purely UI methods, so that they could be changed independently. Another advantage of this is you wouldn't have to worry about incorrectly re-implementing the mutationToDom and domToMutation methods.

I'm totally cool with going with what I have now (less work for me!) but I was just mentioning this is case you guys would be interested. I would be willing to write tests and everything for it.

Module/Package/Etc?

How would you like this to be written? Do you just want it to be a file imported via a script tag or should it be a package like the workspace-search project? I don't have a preference, I just know this was sort of supposed to act as a tutorial in addition to being usable, so idk which option is best.

Tasks

This is a list so you can be up-to-date on my progress, and I can keep track of what I have yet to do.

• [X] Move my branch over to the blockly-samples repo.
• [X] Clean up code.
• [x] Add up and down arrows to procedure args so I can test abstracting callers. -- Needs some fixes.
• [X] Prototype fixing callers.
• [X] Put up PR/Issue for fixing callers.
• [X] Possibly refactor core blocks based on the above?
• [X] Write a bunch of tests.
  
  
  
  • [X] Fix round-tripping statement flag
  
  
• [X] Add input-level minuses to if block.
• [X] Write inline docs.
• [ ] Put up a PR into the samples repo
• [ ] Figure out how to deal with untranslated "variable:" text on procedures.
• [ ] Refactor into a package if it gets accepted

[rachel-fenichel]

Blocks refactor: No, avoid the refactor during this one. But I'm interested in a write-up of your conclusions about the mutator APIs when you're done.

Module/package/etc: Start with a PR with everything in a file that you can include with a script tag. After that (and in a separate PR) follow the example of workspace-search to package it up.

[rachel-fenichel]

@BeksOmega OK to close?

[BeksOmega]

Yep! There are still obvs things related to mutators that could be done. But I think this issue is definitely completed :D