[jira] [Comment Edited] (NIFI-5183) Automatically refresh (local) canvas on component state change

["Dennis Jaheruddin (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161427#comment-17161427 ] 

Dennis Jaheruddin edited comment on NIFI-5183 at 7/20/20, 5:42 PM:
-------------------------------------------------------------------

I agree it feels very akward to have to right click-refresh every time you make a change. Especially when starting a processor. (Connecting a queue to a running processor would be a close second, but for me that is much less frequent).

Some thoughts:
 # We should not impact the canvas refresh schedule if programmatic changes are made, only when someone manually presses a button.
 # It would be sufficient to only refresh what is visible on the screen at that time, and also only things that are connected to the change, but not sure how easy this would be to achieve.
 # Refreshing immediately may not be useful as you could refresh before anything happens. Hence refreshing 'shortly after' is more usefull. Unfortunately the definition of shortly after can differ heavily on your flow.

Based on this I came to the following solution idea:
 * Rather than refreshing once, it may make sense to increase the refresh frequency temporarily. E.g. whenever someone starts a processor, for the next 5-10 seconds refresh several times faster than we ordinarily would have.

An alternate idea which may also be sufficient:

- Refresh once, directly after the processor output has changed. E.g. it shows an error message, or it shows a throughput statistic. Then people will at least know something happened.


was (Author: dennisjaheruddin):
I agree it feels very akward to have to right click-refresh every time you make a change. Especially when starting a processor. (Connecting a queue to a running processor would be a close second, but for me that is much less frequent).

Some thoughts:
 # We should not impact the canvas refresh schedule if programmatic changes are made, only when someone manually presses a button.
 # It would be sufficient to only refresh what is visible on the screen at that time, and also only things that are connected to the change, but not sure how easy this would be to achieve.
 # Refreshing immediately may not be useful as you could refresh before anything happens. Hence refreshing 'shortly after' is more usefull. Unfortunately the definition of shortly after can differ heavily on your flow.

Based on this I came to the following solution idea:

Rather than refreshing once, it may make sense to increase the refresh frequency temporarily. E.g. whenever someone starts a processor, for the next 5-10 seconds refresh several times faster than we ordinarily would have.

> Automatically refresh (local) canvas on component state change
> --------------------------------------------------------------
>
>                 Key: NIFI-5183
>                 URL: https://issues.apache.org/jira/browse/NIFI-5183
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core UI
>    Affects Versions: 1.6.0
>            Reporter: Andy LoPresto
>            Priority: Major
>              Labels: perceived_timing, refresh, ui, ux
>
> This may be captured in [~andrewmlim]'s UI/UX notes, but I propose that when a component state is changed (i.e. started/stopped), the (local) canvas is refreshed automatically. Basically, when new users start a processor, because the canvas doesn't refresh immediately, they do not always get immediate feedback and realize it is processing flowfiles. 
> I also understand that on canvases with giant flows, it is not always performant to refresh the entire canvas on every change. Perhaps just the local process group or N processors, or just upstream/downstream connections could be refreshed immediately, with other components being refreshed from the scheduled refresh action. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)