[BlocklyFeatureRequest]Add ParseInt

Meta
1

Discussion moved to Meta as its more about the forum than the Blockly issue

  1. Wan't sure where to make this post - is this OK for everyone?

  2. When dealing with colours in RGB hex format #FF00FF for magenta etc, I find myself needing to translate them into seperate R, G and B values.

In current JS function mode I do stuff like this

var r = msg.payload.substring(1,3);
r = parseInt(r, 16).toString();
....

but currently if I want to do the same in Blockly I have to write own function to replace parseInt (which I've done successfully)

So I'm wondering if

Does core Blockly already have such a function written?

If it doesn't - can one be written (obviosuly yes)

But either way, should some requests like this be added into the Blockly node or should it stick to basic functions and methods.?

e.g just because we can do it - should we do it?

Simon

2

Shouldn't feature requests for a contrib node be made on the nodes github page?

There are currently 1602 contrib nodes on flows.nodered.org if each node used #share-your-nodes for feature requests they could mask the new nodes that I thought this channel was here to promote?

4 Likes
3

A question we always ask ourselves at the core of Node-RED...

every feature added is one that needs to be maintained, and/or may "block" you into a corner preventing some other future course of action. (pun intended), and/or may make what was a simple node into something altogether more intimidating for a beginner.

1 Like
4

Very good point :slight_smile:
I've created an FR issue on the nodes Github pages instead

Simon

5

FWIW, here's a nice little function that I've used to get the r,g,b values from a hex color string:

let [r, g, b] = msg.payload.match(/[A-F0-9]{2}/gi).map(h => +("0x"+h));
msg.payload = {
    red: r,
    green: g,
    blue: b
}
return msg;
1 Like
6

Yep, you are completely right !!!

But - in contrast to all my other contributions - I created the blockly node for attracting non-technical users to Node-RED. Since I'm a quite technical guy, I'm afraid that this contribution will evolve to a very technical node (when nobody restrains me :woozy_face: ). So I would like to discuss here with some people whether to implement a new request or not (or to solve it another way). When I would have to do that on Github, there will be no feedback from others. Until now the feedback was VERY valuable for me to create something usable ...

Would it be better if I put on my readme file on Github something like this for 'new feature request':

  1. Create an issue on Github
  2. I myself will collect all requests of a new release and create a single discussion on this forum (to discuss all the new features at once)

Then I hopefully can get some feedback, and you guys don't end up with some kind of new Blockly forum.
Is that ok ??

1 Like
7

Maybe there's a few options that could be adopted

  1. A Feature Request sub-category(like the one the main Development one has) in #share-your-nodes

  2. Create a Contrib Node category for general contrib node discussion and leave #share-your-nodes for announcements as @ukmoose has suggested its for

or ???

I do think this Blockly node is worth cutting a bit of slack for (but I am very biased as I am its biggest supporter) :slight_smile:

Simon

8

As the author of a contrib node I would personally prefer that any feature requests are managed/requested in one location.

From a user perspective what happens if I add a feature request in the channel but the contrib node author doesn’t monitor the channel? Does it still get discussed?

9

Of course its up to an individual contrib author where they monitor and want such a discussion to take place.

I think if someone asks for an FR here and author is active here and is happy to keep discussion on here and the Node-RED team are OK with that, then I think its should be OK and just needs putting in an appropriate category or sub-category.

If someone asks for an FR here and author is thought not to be active, I think people just normally direct them off to the authors Github repository.

If an contrib author sees an FR on here and wants it discussed somewhere else, they could just reply and direct it to where they want

Simon