[MUSIC]
Hi, my name is Maribeth and I’m a software engineer on the Blockly team.
In this talk, I’ll discuss some strategies you can use when debugging an application
built on Blockly.
When developing any application, at some point you’ll hit a wall where you have a cryptic
error message or things just aren’t happening the way you expect.
We have several tools that we use on the Blockly team to help figure out what’s going on,
and they can be used in your projects built on Blockly as well.
First, you should know about the Blockly playground.
The playground is a preconfigured environment with Blockly that has several settings you
can modify and debug tools built in.
If you are trying to experiment with the different scroll wheel settings, or working on a custom
renderer and want to see the bounds of each block, or want to compare generator output
between your custom generator and the default ones, the playground could help!
There is one built in to Blockly, or you can even incorporate one into your own project.
I won’t go into detail about it here, because Sam did a great talk at the 2021 summit about
using the playground and other developer tools.
You can find it with previous summit videos on the Blockly developer site.
Next, you should also know about Sourcemaps and how to use them.
Blockly is published as compressed code.
It’s smaller and faster to load for users, but at the expense of being difficult to read
for developers.
If you are debugging your application and you see lines of code in Blockly with difficult
to read variable and function names, that is going to be pretty challenging for you
to understand and figure out which line is actually causing the error.
Fortunately, there is a solution to that and that is Sourcemaps.
Sourcemaps provide a way to show the browser there is a mapping between compressed code
and uncompressed code.
With Sourcemaps enabled, the browser can automatically tell you that that confusing line you’re
looking at actually corresponds to the line `Blockly.FieldTextInput.doValueUpdate_`.
Then, you can read the source code or use the debugger while knowing the uncompressed
line of code that’s giving you problems.
We bundle the Sourcemaps automatically with blockly.
They are in blockly_compressed.js.map and blocks_compressed.js.map.
How exactly you use them will depend on your exact development setup.
If you’re using webpack, you can use the “source-map-loader” plugin.
Using Sourcemaps will ensure you can actually see the human-readable code that you’re
interacting with, which should make it a lot easier to debug with if you are currently
trying to debug with compressed code.
Once you have Sourcemaps set up, you are in good shape to just explore what's going on
in your browser's console.
You can use the browsers developer tools to set breakpoints, view errors and inspect local
variables.
I'll also show you some tips that we use when debugging Blockly.
The first one is Blocky.VERSION.
This is really useful if you needed to check the version.
If you have just updated and you can't find a new method, check to see that you have the
expected version.
So in this case I have version eight.
That's exactly what I thought.
Another useful tool is Blockly.getMainWorkspace.
This function gets the workspace that you don't have to find it in the element browser.
So now we have a workspace and we can explore other properties on the workspace.
We can check the connection checker or the connection database, anything, anything in
the workspace that we want to get.
We now have a handle to this workspace over here without having to go dig around in the
element list in the console.
There we also have Blockly.selected, which does the same thing, but for the currently
selected bar.
So right there I forgot to select a block but if I have one selected and I try again
now I have a block.
And so now the same thing applies where I have a handle on this block so I can check
if I need to debug and check its color or what kind of context menu options it has.
Any properties on the block, now you have a handle to it so you can check it in the
console.
And now that you have that block, one other thing that you might want to do is check the
input list.
So let's say that I would save a reference to this block.
So I have this block Blockly.selected and now
I can look at the input list.
So I'm going to look at blockA.inputlist, and it has two inputs and that's what I expect.
One of them is this boolean input right here that I have a block connected, I have this
True block connected, and one of them is called Do and it's a statement input.
So one's a value input, one's a statement input, and then if I was writing a custom
block, I could check to make sure that my fields look the way I expected so if you're
creating custom fields across the blocks, then exploring this way, it can be really
useful to find out what's actually happening in the block that you're making.
So this first input, the "while true" here we can see it's fields and one of them is
a dropdown, which makes sense because we have this "while" dropdown here and one of them
is a label, and that's just the word "repeat" right here.
So that all makes sense.
Another thing you can do with the block that we've saved is check the connections so we
can check next and previous connections, but this block doesn't have any and this also
doesn't have any output connection.
So let's go after a different block and see what happens.
So if we select this set answer to block, I'm going to call that something else.
But now it's a selected box.
It's really easy to get a handle on it.
And then I can check blockB.nextConnection and here we have a connection because there
is a block in fact connected to the nextConnection.
And so now I can inspect that connection.
So again, if you're creating custom blocks or you're trying to debug, maybe you've programmatically
connected blocks together and something's not happening right with it, then you can
check the connections this way.
And then same for output connection.
So these blocks with the puzzle pieces like this, that's an output connection.
So we need to check what that's connect to that's another way to get it.
And then like we talked about before with the Advanced Playground, you can change any
of the settings here.
So another thing you can check with the advanced playground is the generator output.
So if you're creating custom blocks and you're writing the generator for it, then you can
check what that generator output would be in the different languages and then using
the developer tools, you can even add other generator languages here if you create your
own generator.
But there's a really easy way to test it because it it actually refreshes automatically so
if I add another block here, then it'll actually update automatically.
So that's a that's a really easy way to test your generated output.
Sometimes when you are developing a plugin, you might realize that you need changes in
core Blockly to support your idea.
Therefore, you need a way to locally test changes in Blockly and in a separate application
at the same time.
The way to do that is by using `npm link`.
You can make changes to core Blockly, then build and package blockly using our scripts.
Then run `npm link` which creates a symlink to the package that can be used in other projects.
In your plugin, you can run `npm link blockly` which tells npm that instead of getting blockly
from the npm registry, it should use the locally linked version which just set up.
Then you can run your plugin like usual, but it will use your local changes to blockly.
Doing that, you can make sure the changes you made to core Blockly will work with your
plugin.
This same technique can also be used to link two plugins together, or a plugin with local
changes into your application.
Finally, there may still be situations where you need some outside help.
You probably already know of the Blockly forum where our team provides developer support,
but I want to share some tips that make it easier and faster for us to help you.
You will probably get better answers the more specific you can be.
If you ask “How do I customize the toolbox?”
then most likely someone will send you a link to the documentation or the codelab about
this topic.
If you’ve already read those and you’re confused about a certain topic, then asking
“How can I change the font of a label I added to the toolbox?
Here’s what I tried so far” and posting your code will likely get you a more specific
answer that is more useful to you.
Similarly, your question has to be actionable.
If you say “My code isn’t working” and nothing else, then we have nothing to go on
either.
We need to know what you’re trying to do, and how you’re trying to do it, so post
your code and your error messages too.
Also, it can help to tell us your motivations before diving right into the problem you’re
facing.
It might be there is a better solution to your main problem, and we’re debugging a
solution that isn’t a good fit for your original goal.
Knowing what you’re trying to accomplish can help us steer you in the right direction.
That’s all I have for you today.
I hope these tips help you get unstuck next time you are facing a problem in Blockly!