dnut / app-frame Goto Github PK

The current approach is inflexible with poor readability. Some structs simply won't work because the syntax doesn't match the macro. Also there is no way to specify default or derived values with the existing macro syntax. An attribute-style procedural macro should make this all possible while making the code more readable.

Any components of the app (whether added via init, services, components) will be instantiated separately for each component that depends on it. If you want some component to be shared as just a single instance, like a database connection, you need to do multiple manual steps to make that available. There is not first class support for a singleton pattern.

If you want a component to be instantiated only a single time, it needs to be a field in your app wrapped in an Arc, and you need to manually construct it. Then, you need to also declare it in the provides section with a manual access of that field, or manually implement Provides<Arc<...>>. That means the singleton needs to be defined in one place, then declared as a component of the application in at least three other places. Maybe another design could consolidate that somewhat.

The current approach for singletons is workable, so it shouldn't be replaced with something extremely obfuscated and complex just for the sake of reducing lines of code. It should be obvious how it works under the hood.

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.

Currently you need a single application struct that provides all dependencies. This is typically accomplished with a single global invocation of the application macro. It would be nice if you could instead have one parent application that inherit the components from children applications. Something like this...

struct MyApp;

application! {
    self: MyApp
    children: [DataProvider]
    components: [MyService] // depends on DataComponent, which it pulls in via DataProvider
}

struct DataProvider;

application! {
    self: DataProvider
    components [DataComponent]
}

Maybe application would no longer be the right terminology. Maybe a more streamlined macro should be used.

Ideally, DataComponents could even be declared in a separate crate. But with the current design, I think the rust compiler will complain about forward compatibility issues with trait implementations if they are in separate crates.