No need to get personal.
From your own posts:
So it checks every property of type string (though you are proposing that only happens when the output is expanded).
It is still unnecessary.
No need to get personal.
From your own posts:
So it checks every property of type string (though you are proposing that only happens when the output is expanded).
It is still unnecessary.
If you have a code change to propose, please do raise it in a pr.
We can then review the specifics and consider any issues related to the actual working implementation.
It just seems more elegant if the editor knows from the fieldname, let's say msg._backlinks[]
, that it contains the id of a different item in the flows file.
In the same way the editor knows that the property wires[ ]
in the flow contains ids of other flow items.
Done!
I welcome the review!
I'm still confused as to how/why/what with this PR
Will the PR cause every debug message in the sidebar to have a monitoring property?
No way! Using the monitoring
property was just to give an example of how this looks like.
The goal is that if there's a string
in a debug message that represents the id of a node/flow (and it doesn't matter where this string / id comes from), you may click on this string and get a visual identification around the node/flow(tab) represented by this id / string.
Are you aware there's a similar feature (already present) for numbers
? Just click on any number in the debug panel...
I'll have a sleep and see if it makes sense to me in the morning
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.