You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the event listeners for piral-blazor are installed when a component is mounted. This might be too late, esp. in non-lazy loaded scenarios (e.g., a global Blazor-Pilet installs an interceptor and tries to get an access token).
Background
Right now an application might either be stuck (preview of Piral.Blazor v16) or wait for the 20s timeout (Piral.Blazor v16) when it calls a pilet API function from a global Blazor-Pilet during startup, if createBlazorApi({ lazy: false }) is used.
Discussion
One reason to defer the event listener attaching to the mounting is that only then we have the pilet API of the corresponding component. Maybe having one global set of event listeners (maybe not for all events, but certainly for the pilet API access) could make sense. Any other ideas?
The text was updated successfully, but these errors were encountered:
New Feature Proposal
For more information, see the
CONTRIBUTING
guide.Description
Right now the event listeners for
piral-blazor
are installed when a component is mounted. This might be too late, esp. in non-lazy loaded scenarios (e.g., a global Blazor-Pilet installs an interceptor and tries to get an access token).Background
Right now an application might either be stuck (preview of Piral.Blazor v16) or wait for the 20s timeout (Piral.Blazor v16) when it calls a pilet API function from a global Blazor-Pilet during startup, if
createBlazorApi({ lazy: false })
is used.Discussion
One reason to defer the event listener attaching to the mounting is that only then we have the pilet API of the corresponding component. Maybe having one global set of event listeners (maybe not for all events, but certainly for the pilet API access) could make sense. Any other ideas?
The text was updated successfully, but these errors were encountered: