Organizing Subflow Env Properties

General
,
1

I have a subflow that has a LOT of Env properties (100+). It's a subflow that I created for sending notifications using the HomeAssistant platform to an iOS device. There are a lot of different options when creating such notifications, and I'm trying to make the configuration of this subflow as easy as possible so that folks can pick and choose what they want to do.

The list is able to be scrolled, sure. But it would be helpful if I could organize it somehow. Combine environment vars into groups/sections, or collapse such sections? I see these sort of options in modules, but I'm not seeing them in subflow inputs. Is my only option to create my own module? Would organization of subflow envs be on the roadmap?

Thanks!

2

:scream:

Really?

Surely some sane defaults and built in docs on how to apply the advanced/niche settings by some msg.prop would be much more sane!

I would not hold my breath TBH. Not something i have seen requested and knowing the src code in this area, it would NOT be a trivial task,

3

Hi Steve!

Yes, there are defaults set, the user isn't technically required to use any of these envs aside from 3-4 of them. If the settings do not get set, then they aren't evaluated when building the service call. It's just insanely configurable with these notification behaviors.

And there is the option of passing in a msg for configuration. It's specific use is for overriding the values that are set on the subflow, but you could set the entire config via msg if you wanted.

Would I have more options if I were to make this into a module?

4

Your own contrib node can have 100% custom edit form (full freedom)

But, while i am in the camp of "choice == good" it feels insane there are 100+ things that can be configured! I would relegate the niche stuff to msg settings only leaving the top 10 or 20 things user use most often as options. But thats me.

One way I could think instead of presenting such an overwhelming number of things that can be set might be for your edit form to have:

  • Name
  • Must set fields
  • Top 5~10 most common things user change
  • An editable list that permits the user to "Add" additional config. e.g. each row could be a dropdown (for the setting kind) and a sister field (for the setting value)
5

Yeah, we've been spitballing some ideas for a v2.

Each "action" has 9 configurable env fields, and there are 10 actions that can be sent in. A contributor suggested that we switch from 9 fields -> 1 field, with a JSON type. Provide them a default value/object that they can edit themselves. Would make it more manageable, but would also be a major change.

Thanks for getting back to me! :slight_smile:

6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.