Is there a way to modify the editor UI or to provide an alternative one

Core Development Feature Requests
21

I know this is a long thread and I haven't read it all.

But that is addresses already.
I'm guessing this is to do with things like function nodes.
Most nodes with multiple outputs address this - I believe.

You can define the text shown if you hover over the output pin of the node.

22

I'm surprised you don't find the very first 3 words somewhat negative - "I don't like"... but let's move on.

As I started out with the flow file is the main link between editor and runtime... the runtime can run a flow file without the editor open at all - so yes - if another editor can create a flow file (and then post it to the runtime) then the runtime will run it. Of course they both need a common understanding of what a node can do and on loading the runtime side loads the node's .js file and the editor gets the node's .html file - which describes it's config UI and options. These interactions are described by the admin api - Admin API Methods : Node-RED which should be complete.

The existing UI layout code is at node-red/packages/node_modules/@node-red/editor-client/src/js/ui/view.js at master Ā· node-red/node-red Ā· GitHub - and as you will see at over 5000 loc it is a beast waiting to be tackled.

Have fun hacking

23

I see what you mean. That is definitively a discrepancy between how I perceive it and how others perceive it. For me "I don't like" only means that it doesn't matches my personal preferences or needs, and hence I dislike it. It doesn't mean I find it bad or useless. However I can understand how it sounds from the outside. How do you think something like that should be phrased? "I find them not good for my personal situation". I am being honest here, I want to improve my communication.

That makes sense.

Thanks for pointing it out. I'll have a look.

24

As I mentioned in my previous reply, that code is quite the tangle. It's in need of some serious refactoring before we can make it pluggable in any sense.

As the person who wrote most of the 5000 lines in that file, if you wanted to chat around the sort of refactoring I had in mind (or indeed any other aspects) then I'd be happy to.

2 Likes
25

Sure, I will be happy to. Refactoring some code is a great way to learn how it works.

2 Likes
27

As I mentioned in my previous reply, that code is quite the tangle. It's in need of some serious refactoring before we can make it pluggable in any sense.

Is "refactoring" the right approach?

I don't have any big issues with the Node-RED UI per-se but OMG web dev really has advanced by leaps and bounds since the NR UI was written! I was reminded of that yesterday when, after weeks of writing Vue.js components for the FlexDash dashboard I switched to putting together a couple of nodes and I couldn't help but think about this thread.

The simplest things are soo painful and verbose in the NR admin UI and after getting used to just glancing at my second monitor after hitting 'save' to see the effects with Vue it's really painful to have to restart NR, then reload the admin UI, then click around to get to the edit pane I'm working on to see the changes.

I don't mean this as a criticism, most code written that long ago has long vanished in the bit bucket. I'm wondering whether any thought has gone into what the road forward is (I didn't see anything in Projects Ā· node-red Ā· GitHub). Maybe at this point it's just to focus on a clean API between run-time and admin so the admin can be tackled?

28

A complete rewrite using the current toolkit de jour isn't in the plan. There were plenty of such toolkits around when I started Node-RED and could easily have picked one of them and we'd be in a far worse position. Just look at the fact Dashboard is stuck on angular 1.x.

Rewriting the UI every couple of years to follow the ups and downs of popular toolkits would be a huge waste of time and effort. Not to mention the 3000+ contrib nodes that would have to be kept up to date to match.

The fact the UI doesn't use a particular toolkit has its own advantages.

There's nothing to say we couldn't develop a mode of hot-reload for node html within the current framework. No one has offered up the time and resources to spend on such a feature. I can see a basic outline of how that would work, so may poke around at it after we've got 2.0 sorted.

As for the api between editor and runtime - that exists and is very well defined. Dave linked to the api docs in a previous reply.

2 Likes
29

I guess this coin has two sides...

30

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.