- 550comments
- 763comments
- 200comments
- 88comments
- 354comments
- 5comments
- 69comments
- 61comments
- 64comments
- 74comments
- 18comments
- 57comments
- 7comments
- 37comments
- 183comments
- 35comments
- 8comments
- 38comments
- 13comments
- 2comments
- 31comments
- 1comments
- —discuss
- 9comments
- 21comments
- 73comments
- 174comments
- 51comments
- 433comments
- 103comments
Interesting, interesting. It would take me a few hours of playing with this mechanism to know what I think of it as a primitive, but for me this solution is relevant to a problem I really have so I might take a look. Right now I just write methods that sometimes return a promise and sometimes don't.
Yes, do take a look, I've just added a `log` function that makes it easy to play around with lazy promises and see everything that's going on.
Kind of reminds me of https://doc.rust-lang.org/rust-by-example/trait/drop.html
Do you want monads? Because this is how you get monads.
Author here. What's pretty cool about LazyPromise is that when it's paired with Signals, you can do some of the stuff that you'd otherwise do with functional reactive programming, but you don't have to tell your team to learn RxJS or another FRP library - instead there is an API that capitalizes on the existing knowledge of the native promise.
Interesting stuff!
The two separate failure channels turn me off. Is this practical or does it introduce unwanted complexity in most cases?
Also wondering what are the Signals that are mentioned.
Author here. Good questions.
About the two error channels: what I tried to do is to make it really easy to not use typed errors when you don't need them. In that case your promise is typed as `LazyPromise<Value, never>`.
Signals is a reactive primitive that has been initially introduced in SolidJS framework and have then made their way to other frameworks like Angular.
Quick question - would something like this cover the basic cancelable promise use case, or am I missing something important about what LazyPromise does differently?
Yeah, I think this will cover the basic use-case, although the way I'd approach this is by starting with AbortSignal API and then maybe creating a wrapper around it. In a way `eager` and `lazy` functions from LazyPromise library are such wrappers.
Observability is step one. The hard part is what the system is allowed to do once you observe it.