[
https://issues.apache.org/jira/browse/NIFI-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161427#comment-17161427
]
Dennis Jaheruddin commented on NIFI-5183:
-----------------------------------------
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)
