Hi - I have been using this in production for a few months now, and haven’t experienced significant issues with debugging or troubleshooting.
It also helps that the library is type-safe - if we are overriding a function, we must comply with the signature of the original function for TS to pass.
Wrt. run time errors, the use of proxy does not interfere with good stack traces, if that is what you are worried about.
If we take the example in this gist where an overriden function throws an exception, we can see that the stack trace clearly shows the file (which overrides the hello function) where the exception is originating from.
In effect, the DX is not much different if you use any other mechanism for making some feature runtime configurable. In comparision to most traditional IoC/DI utilities I find the DX to actually be superior:
Unlike a lot of other IoC solutions whose APIs are cloned/inspired from similar Java/C# libraries, you don’t need to wrap things in classes to participate in the DI system
Also, that a function is overridable is transparent from consumer side - they just call a function that they import without needing any @Inject/@Provide boilerplate. This is great if you are writing a library or a small utility and don’t want to enforce usage of a specific DI/IoC library for your consumers.
What we don’t have (and likely will never) is support for things like request scoped DI or hierarchy of IoC containers. In mostly-functional TS code I have seldom missed those patterns.
Imagine the runtime errors
This sounds like a walking runtime error just waiting to happen. Or a litany of them, if you’d so prefer. Debugging would be a nightmare and a half.
Hi - I have been using this in production for a few months now, and haven’t experienced significant issues with debugging or troubleshooting.
It also helps that the library is type-safe - if we are overriding a function, we must comply with the signature of the original function for TS to pass.
Wrt. run time errors, the use of proxy does not interfere with good stack traces, if that is what you are worried about.
If we take the example in this gist where an overriden function throws an exception, we can see that the stack trace clearly shows the file (which overrides the hello function) where the exception is originating from.
In effect, the DX is not much different if you use any other mechanism for making some feature runtime configurable. In comparision to most traditional IoC/DI utilities I find the DX to actually be superior:
@Inject/@Provideboilerplate. This is great if you are writing a library or a small utility and don’t want to enforce usage of a specific DI/IoC library for your consumers.What we don’t have (and likely will never) is support for things like request scoped DI or hierarchy of IoC containers. In mostly-functional TS code I have seldom missed those patterns.