When navigating between pages, the leaving page's Dispose()
gets called after the OnInit()
of the arriving page. This may cause interference with shared states such as Fluxor's.
Example: I've created a working example at https://github.com/Shammah/DisposeAfterOnInit, most notably on https://github.com/Shammah/DisposeAfterOnInit/blob/master/FluxorFoo/Pages/From.razor and https://github.com/Shammah/DisposeAfterOnInit/blob/master/FluxorFoo/Pages/To.razor
The result is as following:
Introduce a proper OnUnmounted()
lifecycle hook that gets called right away when navigating away from a page or unmounted a component, before OnInit()
of the new page or component is called.
Alternatively you could make sure Dispose()
gets called at an earlier stage, but you'd want Dispose()
to remain undeterministic I suppose.
My application happens to have multiple Fluxor states with observable subscriptions, which get re-used across many pages. When dealing with observables, it's best to dispose all subscriptions when they're not needed anymore. In my case however, it happens that some pages will resubscribe on arrival, except the Dispose()
method of the previous page will immediately dispose the newly created subscriptions, rendering the page unusable. In other words, Dispose()
interferes at the wrong moment with my shared state.
I could work around the problem using reference counters and whatnot, but I think a proper determinsitic OnUmounted()
life-cycle hook would be preferable. This is also in line with other SPA frameworks such as Angular and Vue.
Thanks for contacting us, @Shammah.
We'll consider adding a new lifecycle event in a future release.
Any update on this?
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
I find this a blocking issue and now it's moved to the backlog ? Is there any clear examples of how to handle observers and triggering updates to the blazer render engine as it seems to be a fairly common problem. Am happy to be pointed to a resolution / work around for this but have been searching for a long time now and this being on the backlog is a big dissapointment
@mkArtakMSFT Can you guide us with a workaround for this scenario until the feature is implemented ?
@pomeara @Indrajith-Sync if you could provide a clear description about why the existing Dispose
mechanism isn't sufficient in your case, that would help us to know what would make sense as a workaround in your case.
@SteveSandersonMS @Indrajith-Sync I have now worked around this problem and I used this as a way to find a work around / solution
@Indrajith-Sync pop this component into a page and press the buttons and you'll see how the update cycle fails or works based on the way it's invoked
I essentially call await Invoke(AttemptToRender); like this
Hope this helps
@SteveSandersonMS love blazer keep up the great work
I know this issue has a lot of upvotes, but we still don't have an answer to the question I posted above:
if you could provide a clear description about why the existing Dispose mechanism isn't sufficient in your case, that would help us to know what would make sense as a workaround in your case.
@pomeara above mentions a strategy to achieve what they want, and the framework also now supports IAsyncDisposable
, so I think most scenarios should be covered.
People who still think we are missing an important scenario: could you please file a new issue and use it to describe what specific feature you want? For example it might be that people actually want the "option to cancel a navigation event" feature described in a different issue rather than something to do with dispose.
Most helpful comment
Thanks for contacting us, @Shammah.
We'll consider adding a new lifecycle event in a future release.