5 replies

1. 🌧️ jschof 🌼 7 hr later

   @zachleat this is conceptually super cool, but unless I'm making streams an async iterable I'm having trouble thinking of when this would be convenient. Does anyone know of more examples?

   1. Zach Leatherman 20 hr later

      @oldcoyote decoupling a promise from its resolver has been useful for me in a few places (though this code isn’t the cleanest but here’s a deep cut link: https://github.com/11ty/eleventy/blob/c901131cd15d3a65531f25a9804cc9246199649e/src/TemplateContent.js#L442)

2. Max 1 day later

   @zachleat @rauschma I still have PTSD from cleaning up the mistakes of jQuery Deferred (and Dojo and Backbone relatives). I know this new API isn’t doomed to repeat the mistakes of the past and the same sorts of wild callback leaks just because it looks the same as some of the bad old predecessors Promises intentionally replaced, but I still worry what some devs are going to misuse with this all the same.

   1. Zach Leatherman 1 day later

      @max @rauschma we can only control the code bases in our control!

      1. Max 1 day later

         @zachleat @rauschma Sure. But Platforms can still carry the responsibility to try to avoid implementing things that are known to be footgun shaped.

         In my codebases, sure I can just run an eslint rule to avoid this API. Unfortunately, yes, I can’t force my third party dependencies to adopt the same eslint rule no matter how much it impacts me if they shoot themselves in the foot.

         Again, I know I’m worried about a worst case scenario that bad libraries can already do with extra work today.