I was too hasty with merging #4, so I forgot that the library now does not search for the providers that the user created to add them to the service collection.
This means that the user would need to do this theirselves, which is not a great user experience:
services.AddScoped<HateoasProvider<SomeModel>>()
I would propose the following:
When you call AddHateoas() (see ServiceCollectionExtensions.cs) , you can pass no parameters OR you can pass a HateoasOptions parameter (or something like that, take a look at other ASP.NET core libraries for popular naming schemes)
Passing no params means that it will search for all IHateoasProvider and IAsyncHateoasProvider in the current assembly and add them to the servicecollection. I know that this is easy with Scrutor, but I am unsure how to do this without Scrutor. A fun challenge!
Inspired by Automapper, a user could also pass a list of assemblies so we can scan in multiple assemblies. This is useful for when the user has their hateoas providers in a different assembly.
Please keep in mind that #15 might still affect this story a little bit!
I was too hasty with merging #4, so I forgot that the library now does not search for the providers that the user created to add them to the service collection.
This means that the user would need to do this theirselves, which is not a great user experience:
services.AddScoped<HateoasProvider<SomeModel>>()
I would propose the following:
AddHateoas()
(seeServiceCollectionExtensions.cs)
, you can pass no parameters OR you can pass aHateoasOptions
parameter (or something like that, take a look at other ASP.NET core libraries for popular naming schemes)IHateoasProvider
andIAsyncHateoasProvider
in the current assembly and add them to the servicecollection. I know that this is easy with Scrutor, but I am unsure how to do this without Scrutor. A fun challenge!Please keep in mind that #15 might still affect this story a little bit!