Skip to content
Julian Knight edited this page Apr 9, 2022 · 57 revisions

Is there something in this list you would like to see prioritised? Is there something you could help with? Please get in touch via the Node-RED forum, raise an issue here on GitHub or contact me via the #uibuilder channel in the Node-RED slack.

The source for this page is now the docs/roadmap.ms page. That is accessible via the Tech Docs and https://totallyinformation.github.io/node-red-contrib-uibuilder/ - this is only here because people may be familiar with the page. It will not be further updated.


Aims and the future

uibuilder aims and overall direction

The purpose of uibuilder is to:

  • Support an easy method for creating and delivering data-driven web apps.
  • Be a conduit between Node-RED and a front-end (browser) UI web app.
  • Be UI framework agnostic. While VueJS is often used with uibuilder, it isn't a necessary dependency. Indeed no framework will be needed to use uibuilder.
  • Provide interface/data standards for exchanging data and controls with the UI.

The core features of uibuilder:

  • Provide a 2-way communications channel between the Node-RED server (back-end) and front-end UI code.
  • Provide a Node-RED node to act as the focus for communications.
  • Provide a front-end library to do the complex parts of the communications.
  • Provide templates for front-end code to enable people to get a quick start.
  • Allow management and serving of npm packages that provide front-end libraries consumable easily by front-end code.
  • Allow editing of front-end code (designed for small changes, use web development tools generally).

The general direction of uibuilder (or associated modules) is likely to include:

  • An extensible security model.
  • A set of extension front-end components with well defined (reusable) data schemas for doing common UI tasks. The defined data schema's would cover both the component content and configuration data so that both could be sent from Node-RED via uibuilder and any return data structures would similarly be well defined.
  • A capability to have configuration-driven (data-driven) UI's. Creating a framework for describing a UI and translating to actual code.
  • A UI designer allowing users without HTML/CSS/JS skills to create reasonable web apps without code.

Focus for the near future

v5 is the next major release, currently shared as the vNext branch on GitHub. Check the changelog file in that branch to see what has already been achieved and what is likely to make it into the release.

The following is the immediate direction. These are not likely to be incuded in v5.0.0 but are likely to be added to v5.1 or maybe a little later.

Current focus (beyond what has already been developed) is on:

  • Ensuring code quality continues to improve - supported by the split of the code into multiple source components & ever improving code linting.
  • Filling in some gaps and issues identified in various discussions.
  • Continuing to improve the technical documentation. Updating details and changes, adding how-to's, moving some things from the WIKI. Improving language consistency.
  • Maturing the 2 new nodes.
  • Trying, yet again, to think about a sensible but robust approach to security.

Next immediate focus will be on:

  • Possibility of turning on server-side rendering with the EJS template engine
  • Enabling instance npm scripts to be run from the Editor.
  • Displaying and enabling updatable packages in the package manager.
  • Enable templates to provide examples to the Node-RED example library.
  • Enabling security.
  • Add option to auto-install npm dependencies on change of Template.

Longer term focus

  • Creating W3C web components to replace the VueJS ones - especially for the ones baked into the fe code, e.g. the Toast.
  • Creating usable components that have standardised data interfaces. So that other developers can produce similar outputs with different frameworks but the data that is exchanged with Node-RED remains the same. These components should make things easy that flow designers might typically want to do (notifications, forms, charts, tables, drag-and-drop, etc.)
  • Creating a visual layout generator to bridge the gap between uibuilder and Dashboard. Ideally this would be non-framework specific but this seems a very unlikely goal to hit. Would be happy for this to either use web components or VueJS. Svelte might also be acceptable.
  • Possibly the addition of a uib-dashboard node that uses data-driven composition. As a half-way house between code-driven and visual-layout approaches.
Clone this wiki locally