I created node-red-contrib-markdown-note a while ago for my own flows. I’ve finally gotten it to a place I’m happy with, so I figured it was time to share it with the community.
It adds always-visible, Markdown-formatted notes directly to the flow canvas. I wanted to be able to share documentation with less technical users of an open source project I’m working on, as well as “future me” notes.
I've installed your node on Node-RED v3.1.0 on a Raspberry 4-B.
Should the markdown-note appear on the left-hand palette ?
The only way I can add it to a flow is via... Import > Examples
Is that the correct behaviour or am I missing something?
I'm not usually a fan of these exotic Nodes in the workspace that do things they really shouldn't
But I must admit - this has been executed very well, and have installed it, and using it already - kudos!
But one thing to be mindful of - as this is likely using some internal Node RED mechanisms (I have not checked) - it could be fragile and be subject to breaks more so than other Nodes, with every Node RED Update, and could (but hopefully not) - cause workspace glitches.
We'll be adding something similar to the core comment node after v5 - far better for the core comment node to be useful.
All the usual caveats I have to share about nodes that hack the editor to change their appearance in unsupported ways. These nodes could well break in 5.1 as we work to standardize how to do customisations. I can't guarantee we'll add things in ways that work with the hacks being applied without talking to us first.
You've got us over a barrel - reading between the lines:
don't extend the editor because we'll change the APIs in 5.1 coming out in ??? and no we won't standardise the frontend APIs either. So if you want to modify the editor, don't. Accept what we do.
Kinda of unfair and for me a good reason not to upgrade. After all, is 5.x going to bring fixes to the backend (e.g jsonata base64 and group catch-all but not handled or even possible function node features) or just detachable windows in the editor ... and dark theming?
Honestly I don't need detachable windows but I do need a working group catch-all nodes and working base64 encoding/decoding.
This is obviously over sensationalised and Nick didn't say any of this - this is me reading between the lines but my point is that I still see the statement as a bit unfair. If folks implement something that is useful for them, why should they wait until there is a "official" NR way to do it?
As I recently wrote, for me, a better approach would be to offer standardised editor APIs and approaches for extending the workspace with foreignobjects so that folks can get on with solving their problems.
It would also allow folks to experiment and try out new approaches which might or might not be better. One size doesn't fit all in this case.
I don't think you are being fair here Gerrit. Node-RED has always been clear about something: if you use an undocumented "feature", it may break in future versions.
This is hardly unusual, indeed it is totally normal. It is just that many platforms don't need to spell it out or don't bother to. Node-RED flexibility is such that it is absolutely possible to do all sorts of things. But if they rely on undocumented features, you can't possibly have any expectation that they will continue to work in the future. At least without speaking to the core devs - something that Nick has suggested.
This node is an excellent feature addition to Node-RED. But the timing is unfortunate. Even so, there have been quite a few threads in the forum discussing things like this and, again, Nick has tried to outline future plans. There are also design documents on GitHub outlining many of the future design ideas.
They absolutely do not have to wait and nobody has said they do.
As always, Node-RED is open source with a permissive license. People can do pretty much anything they like. But it won't always be guaranteed to work in the future. We should be more than happy that the main developer is prepared to warn us that is the case.
And it would take more development effort. Who will put that in? All of us in the community bear a responsibility if we seen opportunities for improvement. However, the core of Node-RED is quite complex and not all of us have the skills to make active changes. No point in complaining about that if we can't.
This is not at all the way I understand the answer.
Everyone, who is capable of doing this kind of development (I'm not) can of course, do it if they want to the way they want.
Nick is just pointing out that some upcoming changes may break those additional tools. Just a mere warning to the dev and their potential users. No ?
Like many, I am looking at better ways to comment and provide insights to the flows I am developing.
That new node could be an option.
What Julian is doing with UIBuilder, another one.
...
Choices.
And I have taken one-or-two liberties with node-red core things along the way! But I'm aware that they may stop working and so keep an eye on things as they change. I've also tried to feed back possible improvements to core when I can. Or at least highlight which parts might be valuable to expose/document to help with custom node development.
UIBUILDER can help folk with insights in various ways: The uibuilder sidebar perhaps, or custom debugging or inside web pages (I have an example for custom debugging pages).
You're right there, it is a statement of "ok, your using undocumented APIs that will change with 5.1" - ok definitely that's a warning for users of this contrib node and yes that's very fair.
But when is 5.1 coming out? What do I do in the meantime? What are the changes and can I in fact integrate them into what I've already done? I really what this feature now and not with the 5.1 release. What do I do?
That's what I mean with unfair - it's sort of leaving me hanging in the air about should I or should I not use this. Of course, if I do start using this, will the OP maintain the node or leave it to whither when 5.1 comes out? That's another open question. So that's another uncertainty in a very certain world.
And yes, it's my interpretation. And yes, having read both greengolfers and Julians replies, I do see it differently. I definitely did some over interpreting here - kids, don't do this at home!
D'accord - the more the merrier!
I guess I saw a kind of discouragement in Nicks statement that folks might not be willing to experiment for fear of things breaking in the future - that's where I feared that choices might become fewer.
Voila - and that will hopefully also happen with this contribution so that it remains safe to use after 5.1.
I think users should definitely be aware of things that might break and in hindsight that's all Nick was saying and I was over interpreting that - sorry mea culpa
I guess also, interpreting Nicks statement as a potential user of this contrib node or as the author of the contrib node also makes a difference - I was taking the user perspective in my interpretation.
I actually now use this Node - if it becomes a feature in the core - Really Awesome!.. - It does satisfy a real need for me (and my team)...
We use Node RED in production, and something like this is awesome!
Especially if many are working on enhancing flows over many days.
Having something like a sticky note in the workspace, so others can be aware, or a dev to come back to - is just undoubtedly really cool IMO.
Also as per my comment - whilst cool, is subject to lneterence with new internal developments that may cause a breaking change - but that should be excepted with anything that skews away from the official APIs.
@knolleary I hope you don't mind me saying this, but having something like this node offers as a standard feature of the Comment node would be a welcome enhancement.
To be clear, Nick is absolutely NOT saying we are planning to break anything in 5.1 (or beyond). Indeed our record so far is that we have not broken anything (serious) since version 0.x. He is just warning that as this is using undocumented API then indeed at some point we may change something that does break it - and to be fair to us we do need some wiggle room to implement new features that we all want.
In this particular case, what has come up several times recently, is this need/ability to extend the node area ( see also the recent interactive inject node, and previous image preview/debug nodes).
If/when we try to work out a more general solution that may turn into a more formal API then it may require tweaking something internally that may ( or may not) break those existing nodes. Chances are it won’t but until the work is done no-one knows.
Of course coding help with this feature is always welcome and may help it arrive sooner rather than later.
Definitely over thinking! I think a lot of the people in this forum, myself included, give in to that from time-to-time.
In this case, if it is useful, use it! I probably will, I've been wanting something like this for a long time. But just be aware that if you over-use it, you will likely, at some future point, have to change things around.
Thinking about this further has made me bring to the fore something that has been lurking around at the back of my brain for a long time. That revolves around visual programming. Its advantages and disadvantages.
To me, Node-RED covers two really important use-cases:
The platform. Node-RED gives me a server platform that does a load of heavy lifting in terms of maintaining a server/service without me needing to think too much about it and into which I can insert multiple pieces of business logic and ETL.
The flow. This is the actual visual programming part. To me, visual coding is great - until it isn't. And that "until" part is highly individualistic. Some people thrive on a messy spider-web of nodes and wires. I don't, I hate that. So there will always come a point for anything reasonably complex where I will start to consolidate visual aspects into JavaScript code. Simply to reduce visual complexity - to keep my ADD/OCD in check.
I've realised that, in many ways, (1) is actually the reason I keep using Node-RED for more things.
(2) is nice, for sure, but (1) is a game-changer. For me.
How does this relate here? Well, I absolutely want explanatory text in my visuals. To the point where I'd rather have the feature now and have to re-do it later. Whether I use this node or not probably depends on whether its look and layout fits in with my visual style and into the visual style of Node-RED.
Anyway, I'm waffling as usual and I suspect a drink is in order, if only to celebrate selling a house!
Bottom line - use the node if it fits your style! Ignore it otherwise. And if a future Node-RED version replaces it - so be it.
Thanks dceejay, that’s exactly the clarity I was looking for.
I understand the risk: this node relies on some undocumented editor internals and sizing assumptions, so it shouldn’t be treated as an officially supported extension point. That said, I don’t think anything here is inherently fragile beyond repair, and I’ll maintain it and track any breaking changes if things shift in a future Node-RED release.
The whole thing actually started from a comment I came across here on the forum about the node label using Markdown — that was the spark.
It’s MIT licensed, so if a formal canvas extension API does come together, anyone is welcome to use it as reference or a starting point. I’d be happy to contribute to that effort directly too.
I think a lot of the people in this forum, myself included, give in to that from time-to-time.