Frontend

Using Typescript do you prefer your libraries to return promises or something else?

with network requests to e.g. hubs on farcaster we can't get instant returns of data. 

Appreciate feedback on the best way to do it. Here's a proposal by @nazeeh

Farcaster Product Studio @ https://dTech.vision 💜 in love with tech 🤓decentralization, fitness and oldschool rap 😎

Engineer @ Syndicate, prev: Rainbow, Foundation & Cloudflare /poetic-web, builds caststorage.com

Thank for the input mate! Seems like everyone agrees! So @farcasterkit will return promise<t> for e.g. ConnectedAddresses

When you query for them 🤝

I would say Promises is pretty much a standard at this point. Anything async will need them and they are built in to every runtime these days

building • prev manifold.xyz, twilio.com

Yeah one could do await in the library function for you and try to get it to be a call like

let value = sum(1,2);

Where sum(a, b) = a + b;

So it’s atomic?!

Or just have dev do 

let value = await sum(a, b);

Or sum(a, b).then( (c) => value = c;)

It’s about what is the best way to return for a library function

Not sure I get the question.

If it’s an async call, your choice is a promise or a callback. You should choose promise in 2024. It’s composable. Callbacks aren’t.

From the image it seems like Nazeeh is comparing promises vs async/await, but  
they’re both promises, latter is just syntactic sugar.

Hi! My name is Daniel. I am building bountycaster.xyz

Ex Phantom, 0x Project engineer.

From Italy originally, currently live in NYC

Absolutely bias towards promises. Promises are now primitives and can be composed well with other frameworks/libraries

🐵 ← 🙈🙉🙊 → /phil →  phil.cockfield.net, db.team →  
ƒ(🌳) →  🧫 /sys  ←  @cell <T>

That’s interesting tanstack has QueryObserver built in also to the pure TS core that potentially could be used?

An Observable (as another design alternative)?