Does it make sense to use DI container in front end javascript app

Question

I am designing an app with React and its supporting libraries ecosystem. It's going to be a large app, with lots of services and helper modules. To handle the dependency between them, does it make sense to use DI container.

[Update]

Please add missing problems/solutions we have available to prepare a good guideline to include/exclude DI container

Few problems that DI container tries to solve are

It enables easy plug and play of modules Changes in constructor of the modules are limited to service registration

Without using DI container, I have following options

We use factory modules(initaliser) which just instantiate, this will enable plug, different module with same interface and wont require change where it is consumed.

To make it singleton, service module will export instance of it, so that same instance is referred wherever its included.

One thing which will be missing though is single place(registry) where we can find all the dependencies of different modules.

Answer 1

Depends on the case. If app is small then probably no. If app requirements changes often, you use SOLID approach and TS then it makes bit more sense.

It's like asking "Is car good to drive to work?". But we don't know how far is it for you to get from your home to work, do you have where to park, how much are you going spend on gas vs what is the public transportation ticket cost etc...

In general DI helps making code open for extensions but closed for modifications (Open/Close principle). It's always good idea to create high quality code. Sadly from busineess point of view DI in simple projects it will be waste of time and it will make steeper learning curve for frontend people.