Collection of block with little to no function. That is their purpose. These blocks allow you to annotate or comment your blocky scripts. The blocks are converted to actual comments in code. The nice feature of these are not needing to use throw away variables, extra logging blocks, etc. Is under the Library Docs/Comments
Do note that blockly does support comments and this isn’t providing something new but more of another way to do it. I personally don’t like blockly popovers. See Post #3
All of my (Kyle Mason) (mediatech15) blocks are free to copy modify and edit how you see fit. You may re-post the variants freely (an inspired by is nice)
Contains both Free Floating comments (Left) and chain-able comments (Right).
Contains both Free Floating notes (Left) and chain-able notes (Right).
Contains both Free Floating documents (Left) and chain-able documents (Right).
Contains both Free Floating importants (Left) and chain-able importants (Right).
Contains both Free Floating bare comments (Left) and chain-able bare comments (Right).
Gitlab Snippet (RAW)
I just wanted to add a note that Blockly already supports adding comments as a property on a block. Right click on the block, choose add comment and
You can show and hid the comment as desired. But the above lets you create always visible comment blocks which is different. I just didn’t want people to think that this library exists because comments in general are not supported.
Correct and I am aware of that. The popups in blockly to me are well… cumbersome. I personally much prefer to see comments inline (like code) given blockly is only replacing/inserting code. Given the blocks in this are only adding JS comments there is zero harm in functionality. As with everything there are many ways to do something.
I made this based on my personal preferences and the dislike of the built in solution. May not be for everyone but it also isnt harmful (unless there is something I am not aware of in the JS parser).
I agree with this statement I can clarify that in the original post. It isn’t because of lack of support but more of another way to do it based on personal/development preferences.
Another note: you can disable a block with the contextual menu as well, it will then appear in gray/brownish and won’t output any code, like so (see the “log” block color)
If you ever want the rule to actually log the message you can simply reenable it.
But those comment blocks are nonetheless valuable!
Sure and that is useful for things you may log or may not. I think of the enable disable button in node-red on their debug block. This was also incase someone would ever want to copy the actual JS code. This would have normal inline comments.
I personally like the idea, but having used these blocks I found one or two problems:
- No matter which type I used (Comment, Document, Note), when I snapped it before my first rule line (variable) the line got disabled/commented out. It seems there is a Carriage Return/LF missing at the end.
//Variables:thing_tts_speaker = 'sonos:PLAY1:RINCON_123F3F45F8F123456';
item_mediacontrol = 'SonosPlay1_MediaControl';
- The block width is limited. Longer comments/notes do not fit into the block and are not readable in full length. The text field has no multi-line support. Putting together multi-line comments needs multiple blocks?
Maybe I am doing something wrong here with using the blocks, but problem 1 was a bit irritating.
For commenting my rules (line by line) I am using the snapping blocks, of course. (To be clear: That does not mean that I comment EVERY single line in my rules )