search

bootstrapworld / pyret-blocks

Block Language for the Pyret Programming Language
Apache License 2.0
3 stars 1 forks source link

Decide what to do with the dev server page #38

Closed pcardune closed 3 years ago

pcardune commented 3 years ago

As I mentioned in #37, the dev server web pages from codemirror-blocks and pyret-blocks have diverged. The codemirror-blocks version has a tool for replaying redux action logs, which seems generally useful, and the pyret-blocks version has a tool for switching between themes.

If we want improvements to the codemirror-blocks dev server page to propagate to pyret-blocks, we'll need to do a bit of refactoring in both repositories. Is it worth it?

schanzer commented 3 years ago

The question is, "are there bugs in CMB that a language author might discover, which can only be explored in the language module?"

There are certainly bugs in CMB, waiting to be discovered. But ideally the design of the modules is such that a bug found in languageX can be replicated without languageX. And if that's true, there's not much gained by exporting the replay functionality.

Language development involves a few steps:

  1. SRC -> AST: Write a parser for your language, which somehow creates a CMB AST.
  2. AST- > DOM: (Optional) Write some React code for any custom blocks you want to build, either because you don't like the ones CMB provides or because you've added new ASTNodes and you need to render them
  3. DOM -> <screen content>: (Optional) Write some CSS to style those rendered blocks

Steps 2 and 3 seem wildly unlikely to uncover bugs in CMB, and even Step 1 is using the most-used and least-complex part of CMB (literally just exported ASTNodes!).

The hard part comes from interacting with the block editor for languageX. The only language-dependent place where these bugs should be cropping up is in the AST creation: if the from/to fields aren't set correctly or the pretty-printer does the wrong thing, all hell breaks loose. But I don't think debugging that requires a replay button! CMB already throws an error for some of these issues, and I'm sure we can improve the quality of those errors within the library itself, rather than having to refactor.

pcardune commented 3 years ago

Ok, this is very good information to know. Sounds like the answer is that it is not necessary or worth it to combine/unify the dev server pages for pyret-blocks/codemirror-blocks.