e.g a copy button next to the x
Or the add button could duplicate the latest rule rather than defaulting to
I think we need both options really but 90% of the time, when I'm adding something - its very similar to the previous option (which is reason for this FR)
Gets my vote. I am all for simplifying UX. No one likes unnecessary clickage
This was my initial request some time ago & was implemented in the switch node only (and wasnt fully implemented the way i would have hoped - i.e. only the
typedInput selection is duplicated on the next row).
Ideally, I would like to see the
change nodes duplicate all parts of the previous row to the new row.
This feature would be operated either by the existing "add" button or a per row "Duplicate" button (as @cymplecy requested).
The newly created row should be focused after creation to aid keyboard navigation
A keyboard shortcut to operate this "duplicate row" would make adding entries 100% keyboard compatible. (since I also dislike context switching between keyboard and mouse - as it causes me to lose focus! I consider forced context switching poor UX)
sounds good - though not sure 100% duplication in an inject (or change) node makes sense - eg set msg.payload to foo - then set msg.payload to foo... I guess it's workable - but having to then delete payload and write topic (for example) is almost as much work. Also in the mockup shown, would copy/duplicate insert the new rule at that point ? (ie shuffle everything down) - or just add to the end (as the add button does).
I think inserting it after the one being duplicated would be the most intuitive - its easy to move things around if it wasn't quite what was required
It might be same work if just simple set but saves work for a change
There may be a variation required for these nodes but my thought was initially "for consistency".
TBF: I dont mind deleting the duplicated value since pressing
delete is far easier than re-typing
my-custom-long-prop-name over and over again. Additionally, so long as the text is highlighted
on focus the user can simply overtype anyhow
But which field gets focus - msg property, search for or change to?
true - but not so true for an inject. - but yes - I would be happy to see a prototype along these lines (for v4).
The 1st changeable field (usually the operator or msg prop)
I do have plenty of cases where inject is used for testing with some quite complex data and it would be very nice to be able to duplicate it and (manually) add a number to the end of the property name. So that it is then easy to switch between them.
Similarly with the change node - specifically when dealing with JSONata or a JSON input.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.