Q&A

Q&A Format

In our Q&A sessions the team answered a mix of live questions and pre-posted questions based on the published videos. This page has notes from those sessions.

High level topics

Year in review, Roadmap, and Plugins

• Where does plugin documentation live? Can plugins have codelabs?

  • It should primarily be in the README for the plugin, because the README is shown on npm. We would probably take a codelab for something that is highly used, especially if multiple people ask for one.

• Can you say more about the transition to TypeScript? Particularly about people who rely on overriding private functions.

  • Don’t override private functions, please. We are working on improving the API so you no longer need to override private functions. We will keep an eye on common private functions people use and offer APIs for them, or convert them to public if they are widely used.

• Is Blockly ready to use with TypeScript?

  • Yes, it is ready to use with TypeScript. We do have some bugs that are posted on github about it. Overall, I think the general feel is pretty positive.

• What is the expected turnaround time for requested APIs?

  • For APIs that are very specific we are trying to find workarounds. For more common APIs we will publish plugins that rely on overriding something and then try to fix this pretty quickly.

  • We release once per quarter, so once we prioritize an API and begin working on it, generally it would go into the next release. We are focusing more lately on adding new and improved developer APIs, but we are a small team so we can’t promise every API will get worked on immediately after it’s proposed (we welcome contributions!)

• Has there been any discussion about changing the release cadence?

  • We used to release monthly. We decided that it would be better to have less frequent releases so that it is more stable. We do have weekly releases on blockly-samples. We aren’t currently planning to change the cadence.

• What do you think is going to be the hardest part of the roadmap to accomplish? What are you most excited about?

  • I think the transition to TypeScript is going to be painful. We have to update our build system to update to TypeScript so I think that is the challenge.

  • Excited about plugins because they allow people to share code.

  • I want to highlight that blocks and groups of blocks can be a great plugin.

• Can you add more documentation about <insert topic here>?

  • Yes, probably. We need your advice on what topics are not clearly documented yet, and what is tricky about getting started with Blockly development. Some topics are tricky because they require some background knowledge that we are maybe not the best source of knowledge for (e.g. setting up npm or webpack, using frameworks such as React) so there’s a line for us to walk between providing background information and pointing you to outside resources. But we would love to hear your ideas; please post on the forum or open a documentation issue on GitHub.

Build with Blockly

Developer tools, Using Blockly with npm, Codelabs, and How to build a plugin

• In the "Using Blockly with npm" talk, major version bumps were briefly mentioned. How do you determine when you need to bump the major version? Does it happen during the planning stages of a release? Or during the release stages?

  • We are trying to move towards using semver. That means that any breaking API change that is not backwards-compatible gets a major bump. During the planning stage of a release we decide what we’re going to work on the quarter. During the release stage we look for changes tagged with “API change” and decide whether it’s major or minor based on that.

• Will patches for critical issues be backported to earlier major versions (not that I believe this will be common), or is the expectation that projects building on Blockly move lockstep with the major version number changes?

  • No, they will not be backported. We expect developers to continue to upgrade to the latest version of Blockly as we release.

• What's more natural? Using Blockly with Angular or with Reactjs? Especially when Blockly is going for TypeScript.

  • This is up to you and a matter of personal preference. We have examples of both.

• Code often gets compiled and run online. Is there any advice for ensuring that no one comes along and wants to break your site by some nefarious means?

  • You can either sandbox it with a virtual machine or use the Javascript interpreter. Take a look at Neil’s execution talk to learn more about executing generated JavaScript

• Is XML safe? Although it's not guaranteed, there shouldn't be a way to inject nefarious JavaScript code into the XML?

  • Even if you allow a user to handcraft XML, there should be nothing they can do to execute arbitrary JavaScript that could not be written by the blocks in the specified blockly application. We don’t officially guarantee this, but in our history there’s only been, to our knowledge, one case where someone found an injection hole (in the color block, now fixed). It’s not a feature we advertise, but as far as we know, there is no way to escape XML.

Technical Talks

Metrics deep dive, Toolbox APIs, Operator precedence, and Blockly test helpers

• Maybe what we want is not so much to support large workspaces, but to have better support for multiple, interacting, workspaces. What’s the Blockly team’s take on this?

  • We agree, we have many ideas. We’ve heard requests for separate workspaces to edit functions, while still having access to global vars, or having access to functions defined in other workspaces. We might need local variables to do so, so need a way to distinguish between local and global vars. It can be hard to indicate the difference to the user, so it’s an interesting design problem. Would welcome external input.

• Do you know any organization that use Blockly that have opened up their own plugin system for their users? For example, ABC Institution embeds Blockly into their website, but allows their students to create Blockly plugins that only they use in their projects. Is this possible or recommended?

  • Not sure how easy it would be to share functions between different applications, because you need some workspace context to be the same for functions to work (e.g. same blocks available)

• I'm curious how others (or any recommendations) are 'evaluating' Blockly XML programs. Things like comparing to other programs to provide hints, etc.). Are you converting the XML to an AST, for example?

  • MakeCode does a tree diff https://github.com/microsoft/pxt/blob/d0ec5d92f120492142330e264cff57ba5d5cb364/pxtblocks/blocklydiff.ts

• In the Toolbox APIs talk, there's a big focus on the category toolbox. For example, adding CSS classes and custom toolbox items. Are these features available for the flyout toolbox as well? If not, are there plans to add them?

  • No, the flyout toolbox is SVG but the category toolbox is HTML. So the current features only work in the category toolbox. However, we are doing work to make the workspace more extensible, and since the flyout is a workspace, some of that work should apply to the flyout toolbox.

• Is the plan to continue support for both XML and JSON for toolbox definition?

  • Yes, and increase support for JSON. JSON was requested frequently. An example use case is using React, where it is difficult to use XML. You can programmatically create a toolbox definition more easily. In the future it would be nice to also define blocks using JSON.

• How hard is it to add keyboard accessibility support to toolbox items?

  • If you’re using the keyboard-nav plugin, you don’t have to do anything special to work with categories, blocks, etc. If you add things like a search bar, you might need to add additional handling for focus/blur/etc.

• Are there plans to release a search for blocks in the toolbox (as a plugin)? I've seen the workspace search but that's not as relevant for our use case.

  • Highly requested. We don’t have any concrete plans at the moment. Could be difficult to come up with a general search function. Recent toolbox API changes (ToolboxItem) make it easier to implement this feature, and we have a demo.

• One of the codelabs shows using Blockly to create JSON structures. This is a different usage of creating programming code. Is someone combining both 'struct' blockly and ‘programming’ blockly in one application?

  • Blockly can be helpful for configuration objects that have a lot of structure and inputs, and we have seen those kinds of projects being shared in the forum. There are some interesting ways to improve this experience for users, such as block mutators or extensions. If you’re automating your toolbox/block definitions, you could automatically update them when your API changes.

• In the Operator Precedence talk, it addressed how you should deal with precedence when generating code for value inputs. But is there anything you should keep in mind when dealing with fields instead of inputs? Or do fields not cause the same problems?

  • TLDR: The short answer is “no”. Fields are used in code generation, but you don’t have to worry about operator precedence because, calling `getValue` doesn’t return a code-string, it returns some value that you then turn into a code-string.

  • Fields are used in code generation, but you don’t have to worry about operator precedence in the same way that you do for value inputs. Also, to be clear, when I say value input I mean a connection that takes another block, not a type of editable FIeld with a text box, dropdown menu, or similar UI.

In the case of value inputs, you use valueToCode to get the code generated for that input block. The code returned by the input value block might need to be wrapped in parenthesis, but it depends on what code is returned, so you pass operator precedence to valueToCode so it can determine whether it should be wrapped in parentheses.

In the case of fields, calling `getValue` doesn’t return a code-string, it returns some value that you then turn into a code-string. In your generator code you are taking that value and turning it into code. I wouldn’t expect a field value to be wrapped in parenthese, but if you did need to you’d have all the information you need on hand to make that decision because you are generating the code yourself.

• In the Operator Precedence talk, there're a lot of references to "splitting the code" what does this mean exactly?

  • TLDR: “splitting the code” means that the operands on either side of the operator could be grouped with something outside of the expression, if something was added to the left or right of the full expression.

  • When you have an expression, like “1 + 2”, and I ask for the operator where the code could split at, then the answer is the plus operator because, if the whole expression was not wrapped in parentheses then the operand groups on either side could be grouped with something outside of the expression, instead of just being grouped around the plus sign.

So, if I added a 2 times in front of the expression, the “1” could split from the “1 + 2” grouping and instead be grouped together with the 2 times.

As I mentioned in the talk, providing this information will ensure that parentheses are added around the code. So, the “1 + 2” would be wrapped in parentheses if an operator of higher precedence, like the multiplication operator, would be acting on either side.

In the talk I also emphasize “could” when I say where it “could split at” because you can ignore operators that are already surrounded by parentheses or square brackets because the code can’t split there.

Open Questions

• Using Blocky in production also raises the need for testing. Does anyone have experience with unit testing of blocks using blocks?

  • We have generator tests which use blocks to test blocks. https://github.com/google/blockly/tree/master/tests/generators

  • (Anjali) re:tests, definitely not ready, but here's a little side project I've been tinkering on that's basically a library of unit test blocks: https://github.com/ajpal/blockly-testing (proof of concept university project)

• In the continuous toolbox plugin, do you render all blocks eagerly and do you render them once they get into the view?

  • In this demo, yes. But it’s possible to change this and do lazy rendering. We did implement block “recycling” where normally if you change categories, we throw out all the blocks. In this toolbox we don’t do that and don’t re-render blocks when changing categories. That could be application-specific logic so that’s possible to change as well.

• In Abby's Accessible Blockly demo, how did you get the block inputs to highlight on key down events? Would clicking inside of those input areas work? Could this code be repurposed to create a plugin where blocks could be connected by tapping rather than dragging like the Grasshopper mobile app?

  • Keyboard navigation uses SVG elements to show where you are. You cannot click on an input, you would have to create tiny connection points and this might be tedious

  • Blocks for All might be an option since their input are larger. However, the Workspace might get really big and bogged down with the elements on it.

Morning

Evening