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?
New Feature Proposal
For more information, see the
CONTRIBUTINGguide.Description
Right now the event listeners for
piral-blazorare 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?