Hi folks, The godfather of all Blockly nodes (alias @cymplecy) has given his blessing to publish version 1.0.0 on NPM. So here it is finally. @knolleary: I assume you still have to add it manually to the pallette manager index? Thanks for doing that ! Thanks for all feedback and support from the community ! Bugs can be registered on the github repository, and new functionalities or doubts can be discussed here on the forum. The tutorials on the wiki need to be reworked in the next week(s), but they give you a first impression already. Have fun!, Bart

[image] BartButenaers: who are at the moment the two most important men in my life... :sunglasses: Steady on old chap! I am British after all :blush: [image] BartButenaers: What should we do in that case, to avoid things will explode? One of two things I think, of which I prefer the 2nd: 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. "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.

[image] TotallyInformation: 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 [image] TotallyInformation: 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 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 ... [image] TotallyInformation: "Grey out" the node if the NR version is not high enough. This would be my preference 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.

[image] BartButenaers: 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.

[image] BartButenaers: Nice to hear that you are in the mood for extending the blockly node. 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 msg.property || or for a context context.get('property') ||

[image] mikeS7: 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 msg.property || or for a context context.get('property') || 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 || 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 || 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? Simon

@cymplecy Simon, it can be done such way: [image] 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

[image] mikeS7: 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 [image]

Hi Mike, thanks for joining our discussion! [image] mikeS7: add ability to use require-from-string 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)? [image] mikeS7: I want to add checkbox to allow choice what "VM" to use. 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... [image] mikeS7: you added javascript block and we can use new function API 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 ... [image] mikeS7: Could you please add default value to the get method to support javascript style such as msg.property || 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: 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 ... Add a default value somehow to the current get-block. 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 Create a new OR-block that accepts any value. 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.

Node-red-contrib-blockly 1.0.0 available

Share Your Nodes

dceejay 9 September 2018 10:10 52

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.

Topic		Replies	Views
[ANNOUNCE] Visual programming a function node with Blockly - Feedback request Share Your Nodes	206	13398	25 August 2018
[ANNOUNCEMENT] node-red-contrib-blockly version 2.1.0 & 2.2.0 & 2.3.0 Share Your Nodes	19	1028	30 October 2023
Node-red-contrib-blockly 1.1.0 released Share Your Nodes	4	1192	12 December 2019
[ANNOUNCE] node-red-contrib-blockly : 2.0.0 betas (currently at beta 2) Share Your Nodes	31	2246	17 August 2021
Node-red-contrib-simpletime enhancement Developing Nodes	63	2581	4 July 2020

Node-red-contrib-blockly 1.0.0 available

Related topics