minimal UI in sidebar-tab?

[tanpau]

Hi Julian,
just started toying around with uibuilder and i like it very much - tremendous flexibilty and ease of use!
Then I had an - maybe a little strange - idea:
Would it be possible to make a specced-down version of the uibuilder node which deploys its GUI in a new Sidebar-tab???
Then you don't need a new browser-tab for the GUI ... of course only for very basic GUIs (no framework support beside what's the nodered- editor is already using ..), rapid prototyping ... one could also make it detachable like the debug tab ... hmmmm ... just an idea ...
thanks for alll your efforts
stephan

[TotallyInformation]

idea: Would it be possible to make a specced-down version of the uibuilder node which deploys its GUI in a new Sidebar-tab??? Then you don't need a new browser-tab for the GUI ... of course only for very basic GUIs (no framework support beside what's the nodered- editor is already using ..), rapid prototyping ... one could also make it detachable like the debug tab ... hmmmm ... just an idea

🤔 Hmm, interesting idea!

I quite like the idea actually. 😁

My initial thought was whether it could be accommodated in the existing node. But I think you are right, it should be a separate dedicated and simplified node.

I will start to have a think about how this might be achieved.

[TotallyInformation]

Some ideas for requirements. Feel free to suggest more:

• New node to facilitate a sidebar UI ref.
• Single node
• Auto-creates sidebar when added to the page.
• Node should use built-in ACE/Monaco editor with a HTML default template to create the main layout.
• All input elements should automatically send data back to the node.
• Input elements should automatically send data to the output port.
• Check if DOMPurify is enabled in the Editor. It is.
• Check if resources/editor-common.{js|css} are available to the tab. They are.
• Incoming msg's should allow multiple msg.sidebar.<html-id> properties that will automatically update the props on the appropriate elements. E.g. msg.sidebar.div1.innerHTML with a value of some HTML should change the HTML content of the div with an id of div1.
• Apply DOMPurify to incoming and edited HTML content.
• If inputs are part of a form, only send the form data when the form is submitted.
• Create a node-red action to display the tab.

Consider:

• May want to have multiple tabs possible by adding a name setting to the node. Restricting to a single sidebar for now.
• Might need a flag in the uibuilder setting.js prop that allows/disallows HTML content. Or maybe turns off DOMPurify.
• May want an alternative simpler input msg (as well as the full msg type) with just topic/payload that uses topic for html-id and payload for value if it exists on the element or innerText/HTML.

[TotallyInformation]

I don't think that it will be possible to use the other uibuilder nodes - the sidebar IS NOT a web page, merely a fragment of the Editor web page, a panel. As such, it already has a lot of baggage and overheads and is subject to the internal comms and events of the Editor. So the usual comms between Node-RED and a uibuilder enabled page simply aren't possible I'm afraid.

I do already have a simple PoC

It took some working out to get an input message to go to the sidebar and an output button on the sidebar to go to the runtime for sending onwards. But I've got all that working now, in a very simplistic form anyway. I will push it up to the v7.2.0 branch before long so you can see it. It is very rough though at the moment.

but I want the corresponding sidebar-tab to be created/activated dynamically when the 'uibuilder-mini' -node is actually deployed .. (if that's easily possible ...)

It isn't that easy but I will do it. Also, I want to enable multiple uib-sidebar nodes but for now only have a single sidebar UI panel. Some of that is already in place since it is hard anyway to link a script in the panel UI to get back to the runtime. So it is easier to have outputs from the panel go to ALL deployed uib-sidebar nodes.

I'm far from convinced that multiple panels should be allowed since I think that it would be against the design ethos of the Editor. Indeed, I suspect that we will get some pushback even with a single panel but I still think it worth it.

I need to have a think about how to make use of the panel as easy as possible. Not really thought all that through yet.

Since you won't be able to use the no-/low-code nodes directly, you would need to use the uib-html node as an intermediary - that node "hydrates" no-/low-code outputs to full HTML.

Initially, I will probably just allow a msg.html property to set the page's content. But clearly I will need to add an HTML editor to the node itself to be able to persist it. That in itself is relatively complex so might not be in the initial release.

[TotallyInformation]

New node pushed to this repo's v7.2.0 branch. You can install uibuilder manually from GitHub but I recommend doing so to a test instance of Node-RED - I mostly try to keep the development branches workable but you might sometimes get odd errors.

[tanpau]

Very cool :)
am looking forward to delve deeper this weekend ... I managed today to get a sidepanel (catching some editor-events) and a dummy uib-mini-node installed (without any communications), so its going to be an exiting weekend :)) (it's a long time I did anything with express and js ...)
I now think having a single sidebar-Panel for uibuilder is enough (as it comes 'for free' during npm-installation), multiple uib-mini--nodes could have switchable "subtabs" in the panel ... maybe overkill, goal should be: minimalistic, easy, fast, comprehensible.. at least that were my thoughts in the beginning ;)

[TotallyInformation]

Having had a further play with things. I can now get the sidebar added/removed properly. I've also got a basic HTML editor working.

But the next thing I've found is that there are further limitations on how the sidebar is added to the Editor DOM which makes it not only hard to manipulate but very hard to allow user-added script.

So my current thinking is that I will have a pre-build script that will automatically make ALL input elements report value changes back to node-red - no user scripting will be needed which will also make things much simpler for use.

I'll probably work out a better way to allow some level of scripting but probably not for the first release.

With the ACE/Monaco editor in place, I now have to add some processing to allow the sidebar's user-code to change when the user edits their code. Because there is no realistic way of getting a reference to the sidebar's DOM element, this is more complex than it really should be. But I know how to do it now and about 1/2 of the pieces are in place.

I also discovered that the Editor already makes use of the DOMPurify library. So I will hopefully be making use of that in order sanitise user provided HTML code. Should make things a bit safer for the Editor - we don't want users to be able to easily destroy it!

[TotallyInformation]

Update pushed to the repo if you want to take a look.

[TotallyInformation]

Update 3 now pushed to the repo.

Message inputs now work. msg.sidebar.<htmlid> takes an object such that if the UI has an element with an ID of div1 and you send a message containing msg.sidebar.div1.innerText = "Hello there!", the content of the div will be replaced with the text. Most HTML attributes and properties should work.

A message containing msg.reset will reset the sidebar UI back to default.

Any input type element on the UI (e.g. input, select, textarea, etc) will send a message back to the output of the node upon a change of value.

The html content is now more robust in the editor and changes work correctly.

The checklist of requirements above has been updated.