4 ms·
(async () => { set(await get()); })(); get().then(r => set(r)); Ignoring error handling I'll often choose the second option.
by postalrat 6y ago
(async () => { set(await get()); })();
get().then(r => set(r));
Ignoring error handling I'll often choose the second option.
- Rumudiez 6y agoMuch cleaner. You can go even further by using point-free style: get().then(set) It's the try/catch blocks that make async/await truly worse than native promises. I use them sparingly because so often the .then syntax is both clearer and terser.
- postalrat 6y agoWhat don't you like about try/catch? I find the opposite true, the .then/.catch is more confusing.
- Rumudiez 6y agotry/catch introduces new block scopes and interrupt control flow. I find this example very readable, but expanding it into try/catches would make it rather long winded and harder to see the pattern at work as you extend the sequence: get() .then(handleResult) .catch(useFallbackResult) .then(updateState) I prefer concision and functional expressiveness because it reduces the surface area for writing buggy code. Much like how using map instead writing a for loop can eliminate out of range index bugs, chaining promises brings useful guarantees about how the code I do write can be interpreted.
- nailer 6y agoOK. I'll do: const result = await get() set(result) But you do you. Current node and console have top level await BTW.
- postalrat 6y agoThat only works in an async function. The then example doesn't have that requirement. So the alternative shouldn't either.
- nailer 6y agoYes, your example isn't complaining about then() being clearer than await (because it isn't) but rather complaining that top level await isn't everywhere yet. In other words, your complaints have disappeared in node, and will soon in browsers: https://github.com/tc39/proposal-top-level-await https://github.com/tc39/proposal-top-level-await So yes: set(await get())