Very nice article! I'm a full stack developer used to Clean Architecture on the backend. Obviously, the frontend world has a lot of catching up to do in the architecture department. One specific thing that strikes me how is frontend state management (like Redux) should be passed into presentational components by dependency injection instead of the way it's currently done. It has to be said though that DI seems harder to do nicely in the JavaScript/TypeScript world. One reason why DI nicer in the backend is that backend languages allow DI containers to use injectees' static types (since those types are around even at runtime and can be accessed via reflection, unlike in TypeScript). So it seems a DI container in JavaScript or TypeScript will necessarily have a less convenient API,
One specific thing that strikes me how is frontend state management (like Redux) should be passed into presentational components by dependency injection instead of the way it's currently done.
I totally agree. I don't really like the idea of a state management tool being tightly coupled to UI components, but that is probably what library authors want though.
There are some good ways to do DI in the frontend nowadays, with BottleJS for example. Angular also heavily uses DI. Another reason why I don't get why people don't seem to talk about that more.
I just glanced over the docu of BottleJS. It's interesting to see how the DI container API compensates for the language's lack of static types: When you register a service whose "constructor" has arguments, you have to list, during registration, the names of the registrations that should be passed for those arguments. For example, assume that Beer has three arguments:
varBeer=function(barley,hops,water){/* A beer service, :yum: */};
Then, when we register Beer, we have to pass the names of the registrations for 'Barley', 'Hops', and 'Water' during registration:
In a statically typed language, we wouldn't have to list 'Barley', 'Hops', and 'Water' during registration since they would be discovered via reflection from the typed arguments of the Beer's constructor. This is what I meant when I wrote DI containers are less convenient in languages without runtime types.
Be that as it may, BottleJS looks nice.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very nice article! I'm a full stack developer used to Clean Architecture on the backend. Obviously, the frontend world has a lot of catching up to do in the architecture department. One specific thing that strikes me how is frontend state management (like Redux) should be passed into presentational components by dependency injection instead of the way it's currently done. It has to be said though that DI seems harder to do nicely in the JavaScript/TypeScript world. One reason why DI nicer in the backend is that backend languages allow DI containers to use injectees' static types (since those types are around even at runtime and can be accessed via reflection, unlike in TypeScript). So it seems a DI container in JavaScript or TypeScript will necessarily have a less convenient API,
I totally agree. I don't really like the idea of a state management tool being tightly coupled to UI components, but that is probably what library authors want though.
There are some good ways to do DI in the frontend nowadays, with BottleJS for example. Angular also heavily uses DI. Another reason why I don't get why people don't seem to talk about that more.
I just glanced over the docu of BottleJS. It's interesting to see how the DI container API compensates for the language's lack of static types: When you register a service whose "constructor" has arguments, you have to list, during registration, the names of the registrations that should be passed for those arguments. For example, assume that Beer has three arguments:
Then, when we register Beer, we have to pass the names of the registrations for 'Barley', 'Hops', and 'Water' during registration:
In a statically typed language, we wouldn't have to list 'Barley', 'Hops', and 'Water' during registration since they would be discovered via reflection from the typed arguments of the Beer's constructor. This is what I meant when I wrote DI containers are less convenient in languages without runtime types.
Be that as it may, BottleJS looks nice.