Why is asynchronous code in Javascript so complicated and confusing? There are no shortage of articles and questions from people trying to wrap t...
For further actions, you may consider blocking this person and/or reporting abuse
Great article, I stubble with the same issues a while back, and started using github.com/fluture-js/Fluture it basically transforms promises into monads, something like:
I convert all my promises to futures, if it fails instead of catching the error, the map will not be triggered and I can use
mapRej
to deal with the errorfluture is one of those project I have read about, always wanted to use and have never used. I need to block out some time and just use it one day. I feel like even if I don't end up using it I will learn a lot.
Output
One change you'll have to make is to convert all callback-style functions into promise-style functions.
In this case
fs.readFile
is a callback-style function.You can convert it using node's
util.promisify
function like this:Now you can use your promise-style function in the
pipe
.My bad, I should have seen that.
Intrigued. I have a strongly opinionated post draft saved that is spooky similar to what I read from you today. Asking the same questions providing the same examples. I will have a more interested look at your emoji package and the patterns you are adopting.
I'm guessing you are like me and have about a dozen articles in the 90% finished draft state?
Can't wait to see what you are working on!
Although the notation would not be identical. Another thing you can do is write a single function to handle both sync and async and deciding which by its arguments. Asynchronous if a callback is provided, otherwise synchronous.
There's one thing to recognize about await, is that it doesn't "hurt" anything!
So:
and
will always be the same.
In fact, event if action1 and action2 returns a literal value (let's say "hi!"):
and
will always be the same! (mind. blown.)
I for one think you are onto something, where the lines between async and sync can almost always be blurred away. But I think it would take a new syntax. For example:
where
=:
means "resolve the value", and all arrow function are inherently "async".(This is kind of like pointer logic, where you either mean "give me the address" or "give me the value at the address"; but here its "give me the promise" or "give me the value of the promise")
That's true, you could just await everything. You can even do this:
In the case of this problem:
You could do this and not worry.
But I would probably go insane.
while it is true you could await every thing, there is a difference. the await operator will always wait till the next tick to start checking for the resolving of a promise, even if your promise is a literal. But thats just what I read somewhere that I don't remember where, sorry for the lack of reference, yet I'm pretty confident in the information.
I believe you were correct about this. Adding extraneous awaits could have a performance impace.
This looks pretty neat. Having worked with async code before Promises were everywhere, they are a real trip to learn to use. Although the idea is used throughout the programming stack, it's definitely something useful to learn.
I think the coolest part of async/await style is that you can use try/catch to get errors instead of having to add a new function for every promise you unwrap.
Haha that's interesting! That was actually the main reason I disliked
async/await
, I had to wrap everything in atry/catch
.Guess it all depends on what your preferences are.
Wow, Mojiscript looks really well-done. I'm following along now 😄
Thanks! I have been writing functional code for a while now, but I my style and tools has been evolving and I have never laid out a style guide or any rules to follow. So each project tends to be a little different.
This is the first time laid out some rules. Putting in that extra time to create the guide and readme really helped me solidify some thoughts in my head. I think it came out well and I hope to produce some projects that can showcase the language.
Appreciate you taking a peek at it :)
Cheers!
Are you (or anyone else) using Mojiscript in production?
Great question. I wouldn't recommend it for production. I created it less than 2 weeks ago and haven't finalized the API.
I would expect the interface and behavior to change based on feedback. I would consider this version a developer preview.
I am using this framework for a few pet projects of mine that I will open source when ready :)
That's what I figured, but it's well-polished in the presentation that I wasn't quite sure.
lol ya thanks!
but again great question. I'll make this more clear in this article so people don't go launching this into prod yet!
Need more testers. Currently at zero. lol
What about debugging it in most cases although the syntax makes it easy I'm not sure about debugging...
You actually have less debugging because all of your functions become testable.
Try unit testing this:
hint: it sucks.
This should definitely be added into CoffeeScript.
You should be able to import
pipe
into coffee script!