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
Currently the macros are based around the idea that your app describes all of its components in one place. Most other dependency injection frameworks don't need this. You just annotate your component somehow, and it gets picked up.
This approach can already be accomplished with app-frame if you implement the correct traits adjacent to your component declaration, instead of using the application! macro. It's just very verbose, and it's not documented as an option, so it's not likely to be a common approach.
A macro could be added to do the same thing, to make this an explicitly supported use case. However, this could lead to a lot of confusion if people expect the application macro to be the single explicit location where components are associated with an application.
The text was updated successfully, but these errors were encountered:
Currently the macros are based around the idea that your app describes all of its components in one place. Most other dependency injection frameworks don't need this. You just annotate your component somehow, and it gets picked up.
This approach can already be accomplished with app-frame if you implement the correct traits adjacent to your component declaration, instead of using the
application!
macro. It's just very verbose, and it's not documented as an option, so it's not likely to be a common approach.A macro could be added to do the same thing, to make this an explicitly supported use case. However, this could lead to a lot of confusion if people expect the application macro to be the single explicit location where components are associated with an application.
The text was updated successfully, but these errors were encountered: