0 Design: Palette Management UI

Nick O'Leary edited this page 2016-08-13 00:38:22 +01:00

Table of Contents

• Catalog API
• Palette Management UI
• Runtime handling
• Customising the catalog
• Catalogue format
• Further considerations
• To do

Target: 0.15

The runtime admin api provides methods for managing the nodes in the runtime. Add/Remove (by npm module name) and Enable/Disable (at the module and node-set level).

We need to add a suitable UI component to the editor that allows the user to manage their palette.

It needs to provide the following capabilities:

• See what nodes are currently installed - and the module that provides them
• Enable/Disable any of those nodes - bearing in mind the granuality of enable/disable is the nodeset
• Uninstall any of those nodes - at the module level
• Browse a catalog of available nodes and install any of them
• Allow custom catalogs to be provided - via settings.js - either in addition to, or in replacement of the default catalog
• ??? Allow the user to provide a custom catalog url in the editor and then browse its catalog

Secondary considerations

• modify node loading lifecycle so it only loads 'active' nodes - to maximise memory saving

Catalog API

How a catalog advertises what is available.

Two high-level approaches:

1. catalog url points to a json file that provides the content of the catalog. Returns complete catalog every time. The use of ETags on the request/response can be used to prevent unnecessary transfers. All searching etc is then done on the client side. GitHub pages (now) enables CORS, so we could easily host the file via github.

2. catalog url points to a REST api that can be used to list/pagenate results and do search on the server side.

The former approach is the one taken by the Arduino library ecosystem. It just requires hosting a file (that can be generated via whatever means necessary). The latter is what npm does and would potentially put a much higher dependency and load on flows.nodered.org.

I'm inclined to stick with option 1 - but would welcome feedback.

The actual structure of the file is tbd - but must include, for each node:

• name
• description (short - not full readme)
• version
• license (?)
• ...

Palette Management UI

How the user manages their palette. Three distinct views:

• enable/disable/remove what they currently have
• browse and install available nodes
• configure the available catalogs (could be hardcoded in settings.js for initial version)

Runtime handling

Most pieces should already be in place. Need to review whether there should be a hook into storage to deal with add/remove nodes; so it could maintain a package.json file for the user.

Customising the catalog

By default, the catalog will be one we provide. But it needs to be possible customise the list of catalogs it uses. This will be done via the existing editorThemes setting - https://github.com/node-red/node-red/wiki/Design%3A-Editor-Themes

editorTheme: {
    ...
    palette: {
        // An array of urls for catalogues:
        catalogues: [ 
              "http://catalogue.nodered.org/catalogue.json",
              "..."
        ],

        // Customise the order of palette categories
        // (supersedes existing top-level paletteCategories option)
        categories: []

        // Allows the editable palette feature to be disabled entirely by setting to false.
        // Default: true
        editable: true/false
    }
    ...
}

Catalogue format

{
    "name":"Node-RED Community catalogue",
    "updated_at": "2016-08-05T18:37:50.673Z",
    "modules": [
        {
            "id": "node-red-contrib-ftp-env",
            "version": "1.3.0",
            "description": "A node-red node that support FTP file transfer using $() environment variables to control the ftp connection details",
            "keywords": [
                "node-red",
                "ftp",
                "redconnect"
            ],
            "updated_at": "2016-08-05T18:37:50.673Z",
            "url": "http://flows.nodered.org/node/node-red-contrib-ftp-env"
        },
        ...
    ]
}

Further considerations

A use case for providing a custom catalogue is to provide a smaller curated list of nodes - but still picked from the nodes that are publicly available. That will work with the current design where the module passed over the runtime api is assumed to be npm installable from npmjs.org.

Another use case is to provide a catalogue of nodes from an alternative npm repository. In that instance, the catalogue must also provide sufficient information to allow the runtime to target that repo when running the npm install. The runtime api will need to be updated to support this case.

To do

• handle load errors on catalogue - 404/timeout/malformed
• after catalogue is loaded, highlight outdated modules
• ? catalogue-provided curated lists
• ? default 'most recent' list

• Design Notes
• Tech Interchange Meetings