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 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.