Identify and/or fix high-level inconsistencies

[meganindya]

Music Blocks is being built from the ground-up, to address several architectural problems with this run. Since Music Blocks is a fork of Turtle Blocks JS, musical functionality was added on top of it. However, music is fundamental to Music Blocks. Besides, the Turtle Blocks JS started initially with handful of features, and was written without a complex architecture. As Music Blocks got built on top of that, it got incrementally complex, but the architecture remained simple, thus resulting in a monolith. Also, the functionality is tightly coupled with the interface and native client API (Web API).

Keeping these problems in mind, we have considered a foundational rebuild that will address all these issues, whilst adding buffers for future additions. We'll also be using a more elegant tech-stack to develop and maintain this project given its scale. After the core is built, we'll be porting features from this application to it.

The newer build shall replace this as the current iteration of Music Blocks, but this is here to stay. It is perhaps not worth adding new features to this. However, there are some wrap up work that can be done before the new build is completed and this is archived. This iteration incorporates plenty of contributions by lots of people over the last 5+ years of its development and it better be retired in good shape.

Objectives (roughly)

Codebase

• Identify/fix crashes in the middle of some action: Create a pull request if you solve any, or create a new issue if you don't do it yourself (e.g. #2747).
• Remove error logs: There are some error messages in the browser console when the application opens up; fix them.
• Remove debug logs: The browser console by default shows info, warnings, and errors; debug logs are hidden by default, but, there are lots of console.debug statements in the code. Remove unnecessary ones; comment out if some could be seemingly useful during bug fixes.
• Format (prettify) and lint code files: There are tons of linting errors (see #2609); formatting and fixing the linting issues will help simplify some of the other work.
• Code cleanup, reorganization, and documentation: Partly addressed by #2629 and #2630. Please improvise if you feel there's room for something; if something takes too much effort, it better be left out.
• Remove stale code: There's lots of unused code; (carefully) remove them. Consider the benefits and futility of doing this though.

UI

• Minor improvements: Something that makes the UI looks better but doesn't take a lot of effort (e.g. #2707).
• Hack weird UI behavior: Certain UI behavior look awkward and sometimes poor; improvise some work-around if possible (e.g. see https://github.com/sugarlabs/musicblocks/issues/2761#issuecomment-766138220).

Considering the way Music Blocks has been built, the DOM is tightly sandwiched with the logic. The architecture is not hierarchical; all files (irrespective of usage) are imported by the old Require JS style of importing modules, effectively creating a monolith — when the application is loaded, the behavior is as if the code of the all files have been appended one after the other in one big file. Therefore, there is no possibility of unit-testing due to global dependencies and GOD objects. To test anything, please rely on the development tools in the browser. Breakpoints will help a lot during debugging. But, at any time, there will be a lot of variables identified at each breakpoint; please be patient.

[meganindya]

Please feel free to address any of these arbitrarily. You don't need to ask. You can always discuss if you are improvising on something.

[khushal87]

@meganindya Any pending work which I can pick up here and improvise/work on?