Skip to content

Commit

Permalink
Merge pull request #37 from node-red/node-prop-type
Browse files Browse the repository at this point in the history
Node property typing
  • Loading branch information
knolleary authored Jan 8, 2021
2 parents 2232b56 + 4446914 commit 3699a83
Showing 1 changed file with 90 additions and 0 deletions.
90 changes: 90 additions & 0 deletions designs/node-property-typing.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
---
state: draft
---

# Node Property Typing

## Summary

A node's `defaults` object in its HTML definition provides a list of its properties
with some metadata associated with them.

If a property is intended to be a reference to a configuration node, its entry
in the defaults object will include the `type` property that identifies the type
of config node it should point to.

This allows the editor to automatically generate the Config Node select box UI
and manage the relationship between the nodes.

This design note explores extending this property to allow for a richer set of
relationships between nodes.

## Authors

- @knolleary

## Details


### Examples uses

#### `mqtt in` nodes references a `mqtt-broker` node

This is the existing use of the `type` property.
```
broker: { type: "mqtt-broker"}
```

#### `link out` node references multiple `link in` nodes

In the current code, the editor is aware of the `link` nodes and their `links`
property that is an array of ids to partner link nodes.

This design proposes the following syntax could be used to tell the editor
this property is an array of references to `link in` nodes:

```
links: { type: "link in[]"}
```


#### `catch` node references multiple nodes of any type

As with the `link` nodes, the editor knows it has to handle the `scope` properties
of the `catch`, `status` and `complete` nodes as special cases.

Unlike the link nodes, these nodes can reference any node type. This design proposes
this could be expressed as follows.

```
scope: { type: "*[]"}
```

*Note: an earlier iteration of this design proposed `:any[]`. That was inspired
by TypeScript's `any` syntax, but the `:` was added to make it look like a keyword -
as `any` would be a valid node-type. On second though, this didn't look right, so
has been changed to the above syntax.*

#### Node references a single node of multiple possible types

The current model requires one node property per type of config node the node
may have a relationship to. We have had cases where a node needs to reference a
config node that could be of different types (for example, the WebSocket nodes).

The following sytanx could used to list the candidate types:

```
ui_container: { type: "ui_group | ui_widget"}
```

#### Node references multiple nodes of multiple possible types

```
ui_container: { type: "(ui_group | ui_widget)[]"}
```


## History

- 2021-01-07 Updated syntax
- 2020-09-29 Initial design drafted

0 comments on commit 3699a83

Please sign in to comment.