This is an interesting read, but it mostly reminded me how I don't want to invest in a system that forces me to learn a whole new api for doing completely basic and trivial things.
Like defaulting to a value if a response is empty -- everyone already knows how to do that in plain JS, but if you're in the context of an RxJS pipe, you have to know about defaultIfEmpty().
And then consider the actual gotcha from TFA that if you don't use defaultIfEmpty() in the context of a forkJoin(), if any response is empty, then the whole thing silently fails. I would so, so much rather read a few lines of Promise.all, or kick off async requests in a loop and then await to collect responses in a loop, where I can just plainly read and reason about whatever is going on with error handling, timeouts, etc.
And then even moreso all of this when working in a team. Maybe I could even get into this in a personal project, out of curiosity. But I would wouldn't want to ask my team to re-learn how to do all of these mechanics in a new that are already easy enough in the language itself.
Like defaulting to a value if a response is empty -- everyone already knows how to do that in plain JS, but if you're in the context of an RxJS pipe, you have to know about defaultIfEmpty().
And then consider the actual gotcha from TFA that if you don't use defaultIfEmpty() in the context of a forkJoin(), if any response is empty, then the whole thing silently fails. I would so, so much rather read a few lines of Promise.all, or kick off async requests in a loop and then await to collect responses in a loop, where I can just plainly read and reason about whatever is going on with error handling, timeouts, etc.
And then even moreso all of this when working in a team. Maybe I could even get into this in a personal project, out of curiosity. But I would wouldn't want to ask my team to re-learn how to do all of these mechanics in a new that are already easy enough in the language itself.