For the past month, we were assigned by our professor to search for open source projects in GitHub and contribute to them by submitting PRs that address some issues in the projects.
The Project
This time, I decided to work on blockly.
Blockly is a visual programming language, mainly used to generate code into other programming languages, like JavaScript, PHP, Lua, etc. If you have heard of Scratch, well, then you probably know how blockly will look like and work. If you are not sure, you can always check the demo!
The issue
This time, I went with a code clean up issue: #5273: Cleanup handling of potential variables.
Setting up the project
After being assigned the issue, I decided to set up the project and play with it a little.
After cloning the repo, I read over the development documentation to know how should I startup my project, and it was a little tricky at first. After building it up, I thought I had to run the project by opening the HTML file that contained the playground (called playground.html in the tests folder of the project).
I noticed that the page did not look right, so I checked over the console and I notice that none of the files can't be opened because of the CORS rule. Since every file in the local file system is considered to have a different origin, the browser cannot 'request' those, even if they actually exist.
Thus, I had to start up a small http server just to get the files as if I was receiving them remotely. Indeed, opening the HTML this way helped me to actually get a working page and start playing with the application.
Writing code
Most of the time, I start to write code because I know where to go. However, this time, I did not have a lot of context of what workspaces were, or what a flyout workspace is, or even what a potential variable map is! Thus, I ended up reading a lot of code to understand how everything is laid out and how everything connects with each other.
While I cannot say that I know 100% the structure, or even that I understand it, I learned just enough to actually be able to work on the issue. Mind you, this actually took me several tries of painful debugging sessions to know how everything flowed.
In basic terms, every time you add a new variable, we need to keep track of it. This is what the variable map is for. However, flyout workspaces (the ones where they show you a preview of the blocks you can use, like a toolbox) are special, since flyout workspaces keep track of variables that are not actually being used at the moment in the main workspace (the workspace where you place the blocks to connect them). Thus, a potentialVariableMap was used, to keep track of these "potential" variables.
However, the creator of the issue, @BeksOmega, figured out that this potentialVariableMap was not necessarily at all, since flyout workspaces could use the actual variableMap they had available.
Thus, we end up deleting the potentialVariableMap from the codebase, and adjust the code a little so that a stack overflow does not occur.
Funny story: I actually tried to work on this code without having a lot of knowledge over it. After I did the changes I thought were enough, I tested the application and noticed that when I press a specific category of blocks, my browser would freeze for a bit and then I would get a report of a stack overflow in the browser console. It took me 4 hours to actually understand the reason.
The PR
After getting the code ready, I submitted my PR!
Top comments (0)