Node-red-contrib-blockly 1.0.0 available


Steady on old chap! I am British after all :blush:

One of two things I think, of which I prefer the 2nd:

  1. Don't support older versions (as Simon suggests) - actually, I'm not convinced by this simply because of the speed at which NR is developing. There will be lots of people who, for various valid reasons, won't be able to upgrade in a hurry.
  2. "Grey out" the node if the NR version is not high enough. This would be my preference. The block still shows up so people don't wonder where it is, but you can't actually use it. Not sure if this is possible though. Otherwise, generate an error if someone tries to use it with an older version of NR.

As to being able to use the function node's code. I think you may need to contact Nick/Dave on that one.

My gut feel is that it probably isn't sensible simply because you will have created a tight coupling between your code and theirs. This is VERY likely to break something each time the function node is updated.

One possibility might be a PR with a refactoring of the code in the function node so that all of the utility is in an includable module file. If it isn't already. However, this would need careful thought and some planning because that sub-module would need to have a well defined and stable interface defined and documented.

I think that a better approach would be to look at what code could sensibly be refactored such that it could either become part of the RED object with corresponding standardised API or part of some other common library that might be useful to node builders.

In any such case, I doubt this is a 5-minute job and would need discussion with Nick and Dave.


Yes, that is why I posted this question. I have not enough knowledge to solve this at the moment

Yes I also want to do it in the KISS way, but think there are a lot of different Node-RED versions currently running all over this planet. So would like to solve this decently, in some way or another ...

Yes. And by hiding or disabling the block in the toolbar, you get another problem: suppose you are running on an older Node-RED where the block is invisible/disabled. But you import an example flow which contains that block. Then we would run into troubles again. If I generate a 'node.error(...)' there would be no problem in this case.


Good point. So you would still need to error check it, that is true.


The idea was just to add ability to use require-from-string. I want to add checkbox to allow choice what "VM" to use. In version 1.1.0 you added javascript block and we can use new function API without adding a new block (block can be added later). Hope will have the code next week and you can look to continue the discussion.

I want to ask about new feature:

  • Has property in a get block is the nice feature. Could you please add default value to the get method to support javascript style such as || <value> or for a context context.get('property') || <value>


Hi Mike :slight_smile:

I pushed for this (and the set) block to have the simplest syntax possible and to be the 1st blocks in Blockly node as they would be the most familiar things compared to using standard change node.

I would like Blockly to be a stepping stone from standard change nodes to writing JS function nodes directly

I feel it would be better overall if Blockly users just had to put a few more basic blocks together rather than having an overly complicated block that does everything JS can.

the || <value> JS construct is a very neat and useful part of JS but not very common in simple languages

But maybe there could be a separate || <value> block so all that would be needed would be

set myVar to [get msg property payload]
set myVar to myVar || something

What do you think?



don't forget that that syntax doesn't always work as 0, "0", false, etc are all "falsey" in javascript, so while it's a neat shorthand in many cases... it's not 100%. I'd argue it's safer to leave out of the blocks for now.


@cymplecy Simon, it can be done such way:

but I've got:
var1 = 'default';
var1 = (msg['payload']) || var1;

2 lines ... I want only one. OR block allows to connect only logical value or a variable at the second input


Yes - OR in Blockly is designed to just use boolean true/falses values.

Unfortunately, the basic Blockly blocks such as this cannot be altered in what types they will accept.

So to do what you want, I think @BartButenaers would have to add a get xxx || yyy block that accepts any values for xxx and yyy

But going down this route could mean having a Blockly block for every JS syntax possiblity and this is impracticable in the long term

If all it takes is to use two blocks instead of one, then that might be a price worth paying to prevent lots of extra blocks being created


And if you had a need to use a lot of them then I'd just create a simple function to do the job



Hi Mike, thanks for joining our discussion!

Never used that before. Do you want it to add extra libraries, without having to specify them in the settings.js file? If so, can the generated code be copied to a function node (or will the code not run anymore in a function node)?

I have also proposed already a few checkboxes recently, but none of them survived the discussions on this forum :face_with_raised_eyebrow: Indeed we want to happen it all behind the scenes, so our users won't have to bother about the technical stuff. So we prefer not to add extra widgets...

Simon has never been a huge fan of my Javascript block, and I'm starting to understand why. I added it as a last resort, if no other block can be of any help. However I didn't create it to call e.g. Node-RED API functions for which I already have created blocks. So perhaps it is not a good idea to publish the Javascript block anyway.
P.S. It is not much work to add a new environment block, however I just need to have a better mechanism to determine which blocks are available in the Node-RED vesion blockly is running on top ...

That seems indeed to be a reasonal question to me. But I also understand that Simon wants to keep its blocks simpel. And as Dave indicates, it is not fully waterproof...

A summarize of the possible solutions:

  1. Don't add the new feature. But would be a pitty if you have to add 300 extra blocks to achieve such an easy task ...
  2. Add a default value somehow to the current get-block.
  3. Create a new default-get-block which is identical to the get-block, but which allows to specify a default value. But that will result in too much blocks
  4. Create a new OR-block that accepts any value.
  5. Add a dropdown to the current set-block, which contains 'set' and 'set existing' options. When you select 'set existing', the value will only be set if existing. So when you set the default value first, it wouldn't be overwritten afterwards. However then you again need multiple lines ...

I would go for 2 or 4. And my favorite is 2, to keep the number of blocks under control.


Besides to the 'default values' discussion, I have another dilemma...
I'm developing Date/Time blocks, but seems that Javascript standard support for Date/Time lacks some of the functionalities that I need. For example I want to format a date like this:

yyyy-mm-dd hh:MM:ss

Could accomplish this in two different ways, each with their own (dis)advantages:

  1. Currently I wanted to use only standard Javascript, so I generate my own formatDate function:
    The advantage is that it is plain Javascript code, so you can easily copy it to e.g. a function node. But the disadvantage is that the generated code becomes complex, and that my function offers not all functionalities (otherwise it would become too long) ...

  2. I could use the 'moment' node, which is build on top of moment.js. This way I can generate only a single line of code:

    moment().format('MMMM Do YYYY, h:mm:ss a');

    This code is very short and easy to read, but you cannot simply copy the generated code to a function node. Indeed, the user will have to specify the moment node in his Node-RED settings.js file.

Personally I would prefer to switch to option 2, but don't want to confuse users by the syntax errors that occur when pasting the code in the function node...

Any advise on this one ??


Copying code to a plain function node, I think, is a must have feature so that people can "tweak" the Blockly code if needed or want to.

Therefore I don't think moment can be used if it requires editing the settings.js file

I did some googling and came up with this as possible solution


var timestamp, myDate;

timestamp = (msg['payload']);
myDate = '';
myDate = (new Date(timestamp)).toISOString().replace(/[^0-9]/g, "");;
node.status({fill:"blue", shape:"ring", text:myDate});


2 is the last option on earth I would hope you to implement

For all the reasons stated in previous post e.g.1st block simplicity / beginners moving from change node to Blockly node and going "what is this this default thing????"



Ok that was the answer I was hoping for. Just wanted to make sure that I had developed it correctly ...

The toISOString is indeed something that works, and I used that in the beginning. But I wanted to allow other formats like e.g., and that is not possible with the standard Date class.

So I will use the toISOString, and only generate a formatDate function for custom formats. And I will never generate code that uses third party libraries, like e.g. moment.js.

EDIT: The toISOString() method converts a Date object into a string, using the ISO-8601 standard (format is: YYYY-MM-DDTHH:mm:ss.sssZ like e.g. 2011-10-05T14:48:00.000Z). Which label should this option needs to get in the dropdow list: ISO, ISO-8601, YYYY-MM-DDTHH:mm:ss.sssZ, ... ????

When you only say what you don't want, you sound like my wife :wink:
My male neural network has now concluded that Simon only wants option 4. Is this result correct?



I would vote for not having option 4 either but it not the show stopper that option 2 is :slight_smile:
I'd just like to quote an earlier comment


  1. I'd only have it going down as far as seconds to YYYY-MM-DDTHH:MM:SSZ

  2. "long" ? or "long date" [as its a short name :slight_smile: ] Or maybe "full" or "full date"?



Just to say more on the || Block

As I discovered recently, we are "stuck" with the core blocks

I think that getting round a small issue (such as OR not accepting anything other than true/false/a variable arguments ) and making a special block that doesn't really do anything different that a core one but is just a bit easier to use, is not a good idea.

As you know, I wanted text substring block to have shadow number blocks to save me time and mouse-effort in having to drag 2 blocks from the Maths category everytime I used it

I've now just accepted this as a limitation of Blockly.

I am actually starting to think that maybe we shouldn't even have a date block and just carry on with using node-red-contrib-simpletime before Blockly node and just the extrta properties it supplies

And just keep coding up things that are really, really needed inside Blockly node to achieve needed outcomes



I tend to agree. It is tempting to keep adding everything including the kitchen sink. It may be good to pause a while to wait to see what the "real" issues are faced by users. It is always easier to add extra features later, rather than have to deprecate/change/break or remove them later.


I agree 100% that we don't need a kitchen-sink-block ( thanks for the lovely words Dave :smile: ). For example the ioBroker project has a series of blocks like send-email, send-tweet ... Since we already have great Node-RED nodes to accomplish that, we should indeed not add such blocks.

However dropping things like Date/Time blocks is not what I originally had in mind with my blockly node. In my humble opinion a blockly workspace for an IOT application needs to be able at least to process sensor data. This means 'to me' that it needs blocks to support Date / Time / Timers. Therefore I wanted to have those 3 categories of blocks in version 1.1.0.

So I would appreciate if you guys could assist me in designing those blocks, to make sure they become user-friendly.



You write the code and we'll give you the feedback :slight_smile:

BTW Can we change the font to Comic Sans MS.................. :slight_smile: