[n-lark]

Description

Contrib dashboard nodes in a subflow only showed the Size button, so size and order couldn't be set per instance with ${ENV}. Core widgets worked around this with a block copied into all 19 of them.

elementSizer now detects the subflow and shows Width, Height and Order inputs itself. Every node using the sizer gets this for free, and the 19 copies are gone.

• Fixes ui-spacer Order not saving in subflows (typo in the input id)
• On Node-RED 3.x contrib nodes get Width and Height but no Order
• Fixes the subflow fields not showing when Dashboard 1 (node-red-dashboard) is installed. Both register $.fn.elementSizer and D1 loads last, so its sizer replaced ours. The sizer is now picked per node when the editor opens, and D1 nodes keep D1's
• Adds elementSizerByNum, which our sizer called but never defined. Clicking the size label in the popup threw unless D1 was installed

No changes needed for contrib authors. The example node already uses the sizer this way, so it just works.

Test plan

• New Cypress spec, full Cypress suite, npm test, lint
• All 19 core widgets in and out of a subflow: fields, values, ${W} / ${H} / order save, grid picker outside
• Deployed subflow instance renders at its W × H
• Contrib LED, gauge-classic, iframe get the fields. gauge-linear (own detection) unchanged
• With Dashboard 1 installed, core and contrib nodes in a subflow get the fields after drag-in, deploy and refresh. D1 nodes and D1's group editor keep D1's sizer
• Typing a size via the popup label saves it, with and without D1
• Click-through on Node-RED 5 (no D1) and 4.1.1 (with D1)

Related Issue(s)

Resolves #2343

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
  • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production
• Link to Changelog Entry PR, or note why one is not needed.

Labels

• Includes a DB migration? -> add the area:migration label

[andypalmi]

Pulled the branch and ran it locally.

Verified

1. subflow-sizer.spec.js passes (10/10) against a local build.
2. The hidden order input outside subflows adds no change to saved data. main already ships a hidden node-input-order in the widget forms.
3. The ui-spacer fix is correct: the old id node-input-config-order was a typo.

Questions

4. When getEditStack is unavailable, the Order row is never shown. Could a code comment say so?
5. Could the Node-RED 3.x limitation (no Order for contrib nodes) go in the docs?

[colinl]

I am attempting to test this. I am running the branch 2343-subflow-aware-sizer but it appears to have broken the sizer-in-a-subflow feature. Core dashboard nodes that already exist in a subflow are shown correctly, but if I add a new (core) one to a subflow then it shows the usual sizer, not width/height/order. Any suggestions what I may be doing wrong?

[Edit] In fact after a page refresh even existing nodes in the subflow have reverted to showing the interactive sizer.

[n-lark]

Hey @andypalmi thank you for looking, added both. Small correction on 3.x Order still shows if the template has its own order input, which all core widgets do. It's only contrib nodes without one that lose it. The comment and the note in the Subflows doc say that.

[n-lark]

Hey @colinl do you also have node-red-dashboard (Dashboard 1) installed? It registers a jQuery widget with the same name as our sizer and loads after it, so it replaces ours and the subflow fields never get added. I can reproduce it with both installed so I'll look into a fix just wondering if that is the case for you.

[colinl]

@n-lark yes I do have D1 installed.

[Steve-Mcl]

I have not followed along fully but I suspect having D1 and D2 name their sizer widget exactly the same thing $.widget( "nodereddashboard.elementSizer"... BUT have different functionality is a clash:

• node-red-dashboard/nodes/config/ui_base.html

  Line 2450 in 1c749fa

  $.widget('nodereddashboard.elementSizer', {

• node-red-dashboard/nodes/config/ui_base.html

  Line 2450 in 0a82d03

  $.widget('nodereddashboard.elementSizer', {

Renaming flowfuse element sizer to something like nodereddashboard.ffdbElementSizer (or something more imaginative) should solve that (you would also have to update references in code e.g. $("#node-input-size").ffdbElementSizer({

[Steve-Mcl]

I have not followed along fully but I suspect having D1 and D2 name their sizer widget exactly the same thing $.widget( "nodereddashboard.elementSizer"... BUT have different functionality is a clash:

• node-red-dashboard/nodes/config/ui_base.html

  Line 2450 in 1c749fa

  $.widget('nodereddashboard.elementSizer', {

• node-red-dashboard/nodes/config/ui_base.html

  Line 2450 in 0a82d03

  $.widget('nodereddashboard.elementSizer', {

Renaming flowfuse element sizer to something like nodereddashboard.ffdbElementSizer (or something more imaginative) should solve that (you would also have to update references in code e.g. $("#node-input-size").ffdbElementSizer({

That said, it would probably break existing contribs using elementSizer - bah! - this should have never happened in the first place :(

[n-lark]

@Steve-Mcl yahhh I thought the same thing but renaming would break all the contrib nodes so instead I made the sizer get picked per node when the editor opens. Dashboard nodes get ours, D1 nodes keep theirs.

I tested with and without D1 and seems to be working. @colinl mind giving it another go? Just restart Node-RED after pulling. Thank you sm for catching this, never would've found it on my own.

[n-lark]

This is just ported over from node-red-dashboard - we call it and it would throw unless d1 was installed.

[colinl]

All good now. Tested with @colinl/node-red-dashboard-2-ui-gauge-classic and @hotnipi/node-red-dashboard-2-ui-edgewise-meter.

[Steve-Mcl]

@colinl could you post a couple of screenshots of the edit panels of both those nodes please (one where the sizer is shown, one where the fields are shown) - I am curious as to how they affect layout and if we should inline them!?

[colinl]

@Steve-Mcl, Certainly