e.g a copy button next to the x
2 Likes
Or the add button could duplicate the latest rule rather than defaulting to
Set msg.payload
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).
Notes and thoughts if this proposal is accepted...
Ideally, I would like to see the inject, switch and 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)
2 Likes
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)
1 Like
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.
