This one was my biggest challenge which was a combination of issues. This is not an issue with Timeline per say, I just want to post in case others have a similar implementation issue.
The first issue is that all handlers for Timeline are created during bootstrapping of my app not upon request and are created as singletons. Two, my platform Blazor frowns upon using HttpContext which is used for the Identity Service (Blazor and shared state). Third which is minor is the memory footprint of having all command and event handlers created in memory instead of on demand.
This is a cascading of errors. The solution for Blazors HttpContext issue, according to the docs, is to capture data prior to the user starting the Blazor app. Prior to the user crossing over to Websockets capture the identity information and pass the information to Blazor. Then store that information into memory using something like Fluxor. The issue is Timeline was bootstrapped when the App started not when the user accesses the app. The dependencies injected into CommandQue and EventQue at boot up are prior to the cross over. Furthermore, all objects are singletons. Timeline now has concrete objects with state information prior to the cross over, no identity information. When a Blazor Page is created the CommandQue injected into it is NOT a new one, but the one created when the app started. Therefore, no user identity.
The solution to my problem was to create a Handler Factory which would create the handlers, commands, events, overrides, and process managers. Instead of subscribing concreate objects to Command Queue or Event Queue making all things singletons. I store a Handler Description in Handler Factory which would describe the handle method and the class/object it is in. I register the handlers into the DI Container as per instance. I add handler/handle descriptions to the Handler Factory not concrete objects but the description of those objects. The Handler Factory is the only thing added to the DI as a singleton. I add IServiceProvider (Microsoft’s DI service locator) and IHandlerFactory as dependencies to CommandQueue and EventQueue.
After making those changes when a Blazor page is created with CommandQueue dependency it is injected into the Blazor page as a new object. Furthermore, the CommandQueue receives a IServiceProvider giving it access to the DI Lifetime with the containers current state instead of the state at the start of the app. When CommandQueue or EventQueue needs a handler, they call a method in the Handler Factory passing the IServiceProvider which was injected into them. Using the list of handler descriptions and the IServiceProvider passed to the Handler Factory it will resolve the handler that needs to be created. The handler is being created pre request using a current DI Lifetime any dependency for the handler will be created with the current container as well. The result will be a Handler with current state hence the identity will be current. One additional piece to the puzzle, Handler Factory has a IHandlerResolver injected into it and the implementation on how to create/resolve an object is not done in the Handler Factory. This provides a means to resolve objects based the need at hand. For the app I use AutoFac for unit testing I use an in-memory list and Moq.
- Call GetCommandHandler on the Handler Factory passing the ICommand and IServiceProvider
- Find the Method/Class description for the handler of the given ICommand
- Call the Resolve of the IHandlerResolver passing IServiceProvider and the Class name from 2. to create/resolve the object
- Create the object Handler with the handle method
- Passing the handler back to CommandQ
This one was my biggest challenge which was a combination of issues. This is not an issue with Timeline per say, I just want to post in case others have a similar implementation issue.
The first issue is that all handlers for Timeline are created during bootstrapping of my app not upon request and are created as singletons. Two, my platform Blazor frowns upon using HttpContext which is used for the Identity Service (Blazor and shared state). Third which is minor is the memory footprint of having all command and event handlers created in memory instead of on demand.
This is a cascading of errors. The solution for Blazors HttpContext issue, according to the docs, is to capture data prior to the user starting the Blazor app. Prior to the user crossing over to Websockets capture the identity information and pass the information to Blazor. Then store that information into memory using something like Fluxor. The issue is Timeline was bootstrapped when the App started not when the user accesses the app. The dependencies injected into CommandQue and EventQue at boot up are prior to the cross over. Furthermore, all objects are singletons. Timeline now has concrete objects with state information prior to the cross over, no identity information. When a Blazor Page is created the CommandQue injected into it is NOT a new one, but the one created when the app started. Therefore, no user identity.
The solution to my problem was to create a Handler Factory which would create the handlers, commands, events, overrides, and process managers. Instead of subscribing concreate objects to Command Queue or Event Queue making all things singletons. I store a Handler Description in Handler Factory which would describe the handle method and the class/object it is in. I register the handlers into the DI Container as per instance. I add handler/handle descriptions to the Handler Factory not concrete objects but the description of those objects. The Handler Factory is the only thing added to the DI as a singleton. I add IServiceProvider (Microsoft’s DI service locator) and IHandlerFactory as dependencies to CommandQueue and EventQueue.
After making those changes when a Blazor page is created with CommandQueue dependency it is injected into the Blazor page as a new object. Furthermore, the CommandQueue receives a IServiceProvider giving it access to the DI Lifetime with the containers current state instead of the state at the start of the app. When CommandQueue or EventQueue needs a handler, they call a method in the Handler Factory passing the IServiceProvider which was injected into them. Using the list of handler descriptions and the IServiceProvider passed to the Handler Factory it will resolve the handler that needs to be created. The handler is being created pre request using a current DI Lifetime any dependency for the handler will be created with the current container as well. The result will be a Handler with current state hence the identity will be current. One additional piece to the puzzle, Handler Factory has a IHandlerResolver injected into it and the implementation on how to create/resolve an object is not done in the Handler Factory. This provides a means to resolve objects based the need at hand. For the app I use AutoFac for unit testing I use an in-memory list and Moq.