Markdown node: select property

[gregorius]

Hi There,

is this a core development issue if a I put in a PR for the node-red-nodes repo --> Markdown parser: add property selection by gorenje · Pull Request #1109 · node-red/node-red-nodes · GitHub

I have a use case where I have markdown content defined on a property other than payload and instead of adding two change nodes, I was thinking of bring the markdown node inline with the base64 node where a property selection is possible.

Cheers!

[marcus-j-davies]

Whilst I don't use the markdown Node - My (maybe unimportant) input, is why not?
in its current state - its uneventful.

[Steve-Mcl]

Any changes that add typed input and permit a property other than payload, removing the need for extra change nodes gets a big +1 from me.

I spent a lot of time adding this to core nodes but it met resistance: Support Property in out on core nodes by Steve-Mcl · Pull Request #4656 · node-red/node-red · GitHub (Tons of details and screenshots in the issue: FR: core nodes to permit input and output to properties other than the hard coded payload · Issue #4651 · node-red/node-red · GitHub)

As for posting here good question - its probably more suited to General or Developing Nodes TBF

[marcus-j-davies]

@Steve-Mcl

I spent a lot of time adding this to core nodes

What I meant to say was - its a brilliant Node, and really eventful, and full of colour and flexibility

[gregorius]

I pushed over to developing nodes, seems to fit there too

@Steve-Mcl

I spent a lot of time adding this to core nodes but it met resistance: Support Property in out on core nodes by Steve-Mcl · Pull Request #4656 · node-red/node-red · GitHub (Tons of details and screenshots in the issue: FR: core nodes to permit input and output to properties other than the hard coded payload · Issue #4651 · node-red/node-red · GitHub)

Wow that's a lot of work - I would definitely support it .... but I would avoid the propertyIn & propertyOut - I prefer the one property with the assumption that it gets overwritten by the node ... but that's my cup of tea.

But I see I've touched on something that has already been discussed ... so I doubt that my PR will go anywhere. Good thing that I can just overwrite the node in my installations

[gregorius]

@marcus-j-davies

and full of colour and flexibility

Sounds like a song fresh out of the 60s - "My nodes are full of colour and flexibility"

[gregorius]

As an aside: it just occurred to me that JSONata has $base64encode and $base64decode which really makes the base64 node obsolete. It fact using JSONata allows me (and I have a use case of this) to convert four different values to base64 in a single change node, eg:

I think there could be a case to be made for creating a $toMarkdown in JSONata which would also take options that could be passed to markdown-it - which isn't possible with the markdown node.

An argument against would be that markdown isn't that universal as base64 or it's not a "computation".

I don't know, seems like it could be a possible good idea.

[Steve-Mcl]

@gregorius

. but I would avoid the propertyIn & propertyOut - I prefer the one property with the assumption that it gets overwritten by the node ... but that's my cup of tea.

With separate in/out you can chain nodes without a single change node.

Node	input	output
inject	na	msg.payload = { url: "", brightness: 0.85, saveTo: "/var/file"
http-request	msg.payload.url	msg.rawImage
image-node	src: msg.rawImage brighnessValue: msg.payload.brightness	msg.modifiedImage
file-node	path: msg.payload.saveTo, data: msg.processedImage	na

At no point was payload overwritten and could be used again and again without ever moving/copying in a change node and, more importantly, it was still present at the end of the chain as well as the individual node results are present in their own props in the last msg. This becomes important for things like chaining ModBus requests or HTTP Requests and needing both/all results at the end.

[Steve-Mcl]

@gregorius

As an aside: it just occurred to me that JSONata has $base64encode and $base64decode which really makes the base64 node obsolete

FWIW, the base64 node is an extra (not a core) node

@gregorius

I think there could be a case to be made for creating a $toMarkdown in JSONata

Since markdown is a core component in the runtime, and JSONata is not going anywhere, I would not block that feature.

Please note, for me, JSONata for anything more then a simple one-liner is almost always skipped in favour of JS. JSONata, in my tests, is prohibitively slow by comparison to the JS equivalent
Ref: flow-timer. A simple subflow to measure time taken in parts of your flows. · GitHub 4ms vs 1222ms

[gregorius]

@Steve-Mcl

FWIW, the base64 node is an extra (not a core) node

so is the markdown node but they both live in the same repository, i.e, kind of node-red contrib but maintained by node-red!

@Steve-Mcl

Since markdown is a core component in the runtime, and JSONata is not going anywhere, I would not block that feature.

I was thinking of this too, that markdown-it is included anyway so adding a "node-red special function" to JSONata won't alter the universe that much and perhaps improve Node-RED that little bit.

@Steve-Mcl

prohibitively slow by comparison to the JS equivalent

convenience versus speed - I find using JSONata far more convenient than a function node. Ok and I also what Erlang-Red and Node-RED to be as compatible as possible so I've been using a lot of JSONata to make flows work on both.

I find it a pity that JSONata has such a bad-rep since the integration into the flow editor is absolutely brilliant - with a tester builtin and all functions documented - what more could one want. In comparison a function node isn't half as good - considering there isn't any JS documentation builtin

Are there any ideas why JSONata is so much slower?

As an aside: in Erlang-Red, I also support JSONata - I created an extra parser for the language. Obviously the parser can't generate JS code for the JSONata stanzas, but instead it generates Erlang code - it literally translates the JSONata to Erlang code that is then compiled into BEAM code (the byte code which is interpreted in the Erlang runtime).

Originally I did the compilation to translate and compilation at runtime, i.e., when a message would arrive. This I noticed was too slow. So what I did instead was do the compilation at deploy time and then use the byte code when the message arrives, i.e. no recompilation of the same code. Major improvement.

The point is, how does Node-RED JSONata work? Does it translate to JS code or does it have its own engine, is there a compile step? Perhaps there are some quick fixes for some quick wins....

@Steve-Mcl

At no point was payload overwritten and could be used again and again without ever moving/copying in a change node and, more importantly, it was still present at the end of the chain as well as the individual node results are present in their own props in the last msg.

I can definitely understand having both In & Out - here again, convenience v. speed, is it faster to have two or one property to configure? Is it more convenient not to have extra change nodes for stuff that can be done using property mappings? Is it more confusing when a message suddenly has a new property? Where was the property set? Which node set it? Currently I can easily identify the node because it has to be a change node, all other nodes "should" only inactive with the payload attribute - that's my understanding.

But there is no hard and fast rule that says "visual programming shall only have one or zero properties that can be set by a node". So this is a perfect example of doing some A/B testing and finding out how users react!

For me, having nodes only act on the payload attribute is a good thing ... but ... then ... oh ... just this once a node can act on another property! And then it falls down. And then the user can set the property on which the node should act. But only if that property is overwritten and no other property is "automagically" created.

Sorry for the long reply - it's Friday and I've got to do something but I'm procrastinating because I don't want to do it.

[bakman2]

@marcus-j-davies

My (maybe unimportant) input, is why not?
in its current state - its uneventful.

Keep in mind that the markdown node has full support for mermaid, which makes (flow)charting etc very simple. Even a simple bar chart can be made with some text only, ie:

``` mermaid
xychart-beta
    title "Sales Revenue"
    x-axis [jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec]
    bar [5000, 6000, 7500, 8200, 9500, 10500, 11000, 10200, 9200, 8500, 7000, 6000]

renders:

[dceejay]

@gregorius

but they both live in the same repository

Hi @gregorious, I’m more than happy to look at the “simple” PR you suggest.

[TotallyInformation]

I'm all for getting appropriate flexibility into the nodes. Though I find it a pain in the proverbial to actually code, the use of typed input really does enhance nodes a lot.

I have fairly regularly come across use-cases where extra change nodes are needed and it does distract from the flow logic and is easy to trip over. So this would have my vote.

[gregorius]

@marcus-j-davies

My (maybe unimportant) input, is why not?
in its current state - its uneventful.

If you mean that you don't have a use case for the markdown node, my use case is actually generating documentation for my nodes Because I dislike creating html content, I use markdown and convert that to html which is then inserted into the documentation part of the node. E.g. the markdown is converted to the documentation for the genserver node.

@dceejay

I’m more than happy to look at the “simple” PR you suggest.

Cheers! I tried to keep KISS - keep it super simple - so if you do merge that would be great. Btw I also noticed that the versions don't match - in the repo the markdown node as a version 0.5.0 yet in the catalogue I have 0.1.4.

Btw2:

Who's going for node package 5555?

[TotallyInformation]

@gregorius

I use markdown and convert that to html which is then inserted into the documentation part of the node.

For node-red nodes, I believe that you can write the help for the node in Markdown anyway can't you?

As I write my nodes using VS Code, I have a couple of markdown extensions loaded which makes things even better. Of course, the uibuilder nodes have built-in full documentation and that simply uses Docsify to dynamically convert markdown to html on the fly. There are a number of Docsify extensions built into an app.js so you don't have to mess with extensions needing to be loaded separately into your node-red instance and so that the whole thing works perfectly offline, not just online.

Also, for more complex documents - typically with large tables, I use Typora for that. My documentation markdown files are also linked into Obsidian so I can work there as well.

[Steve-Mcl]

@TotallyInformation

For node-red nodes, I believe that you can write the help for the node in Markdown anyway can't you?

Node help style guide : Node-RED

[gregorius]

@Steve-Mcl

Node help style guide : Node-RED

AAAAhhhhhhhaahahahhh -

Since 2.1.0 : The help text can be provided as markdown rather than HTML. In this case the type attribute of the <script> tag must be text/markdown .

Well why didn't anyone tell me before

Cool, then I can work directly in Markdown, much better!