TL:DR; it is indeed non-canonical, in a perfect world, the use case is independent from the framework.
In a canonical implementation, the use case function would be located outside the hook, and the services would be passed to the use case via the last argument or via a DI
In the sections' examples, I show how to do it using DI with the last argument for the use case. Basically, we're just passing all the things we gathered from hooks via object. If we did that, the hook would become just an adapter which is better.
However, it is not always reasonable to do. In this case, for example, hooks are used just as “DI” to inject services and work with data storage.
Also, notice that even using hooks as DI, we don't mix up the use case function and the hook that is exposing the use case to the UI. The use case is still independent from the framework.
Conceptually the hook is already just an adapter and not a part of the application layer. It's just located there because of my laziness :–)
I think that the main reason for using clean architecture in frontend projects is to be able to replace a UI library with a different one with minimal effort. By making non-UI layers dependent on React, we lose this capability.
Depending on the UI library in question, you will probably never be able to just "swap it out", and in most environments, the dev shop will have created a design system, an accepted UI suite to use (material, kendo, etc) and will hardly ever change. The real flexibility is in portability and extendability, which is more-so for your own libraries you write, not the application itself. The application is the implementation detail, and your libraries are where the clean architecture matters the most.
So long as you have decent organization and have well-built and taken-care-of library architecture, your application will probably just use the library and mock/override what is needed.
This is why Angular uses modules and allows you to inject provider overrides. React is more open-book, which is where a hook-driven DI makes sense. React Context and several other state management tools also aide in dependency injection and overrides, it's just a matter of what you prefer.
Thanks!
I described this nuance in these sections of the post:
TL:DR; it is indeed non-canonical, in a perfect world, the use case is independent from the framework.
In the sections' examples, I show how to do it using DI with the last argument for the use case. Basically, we're just passing all the things we gathered from hooks via object. If we did that, the hook would become just an adapter which is better.
However, it is not always reasonable to do. In this case, for example, hooks are used just as “DI” to inject services and work with data storage.
Also, notice that even using hooks as DI, we don't mix up the use case function and the hook that is exposing the use case to the UI. The use case is still independent from the framework.
Conceptually the hook is already just an adapter and not a part of the application layer. It's just located there because of my laziness :–)
I think that the main reason for using clean architecture in frontend projects is to be able to replace a UI library with a different one with minimal effort. By making non-UI layers dependent on React, we lose this capability.
Depending on the UI library in question, you will probably never be able to just "swap it out", and in most environments, the dev shop will have created a design system, an accepted UI suite to use (material, kendo, etc) and will hardly ever change. The real flexibility is in portability and extendability, which is more-so for your own libraries you write, not the application itself. The application is the implementation detail, and your libraries are where the clean architecture matters the most.
So long as you have decent organization and have well-built and taken-care-of library architecture, your application will probably just use the library and mock/override what is needed.
This is why Angular uses modules and allows you to inject provider overrides. React is more open-book, which is where a hook-driven DI makes sense. React Context and several other state management tools also aide in dependency injection and overrides, it's just a matter of what you prefer.
I use TypeScript + MobX and can change React to Vue or Angular at any time. So it depends on the architecture of your application.