Language:
switch to room list switch to menu My folders
Go to page: First ... 38 39 40 41 [42]
[#] Mon Oct 19 2020 15:47:15 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


that appears to be correct.

[#] Mon Oct 19 2020 16:46:33 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


you always have a choice to use either `await` or the Promise API directly with .then()/.catch()/.finally().

My coworker, who does a lot more JS than I do, says "I find it a little easier to handle errors from endpoints with .then()." but I'm not sure what he means by that.

[#] Sat Dec 26 2020 15:36:18 EST from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Finally got a chance to play around with this a little bit. The biggest problem is that the calling function must be asynchronous to begin with, which can be a problem if you're trying to do something in an iterative fashion. So I ended up with something like this:

function my_function() {
fetch_function = async() => {
response = await fetch("/whatever/url");
the_data = await(response.text());
if (response.ok) {
do_something_with(the_data);
}
}
fetch_function();
}

Not perfect, but it definitely saves a few lines over manually setting up an XmlHttpRequest() and getting into callback hell. I am trying hard to avoid bastardizing the way the API is supposed to be used, so there's going to be some learning ahead.

[#] Tue Dec 29 2020 19:09:14 EST from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Yes exactly. This guy posted a brilliant RANT on that subject: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/



It's like the rant of all rants. I bow at the altar of this rant.

async/await is finding its way into other languages, now. Python, if I remember correctly. IT'S LIKE A VIRUS THAT MUST BE STOPPED! VERY 2020!

Hiccup.

Anyway, I had to do a bit more JS work a month or so ago. I was integrating the Orion CodeEdit widget with our project. So I took a look at our build toolchain. I could have just loaded the Orion dist bundle directly as an extra <script> tag, but I wanted to do it the "right" way, and learn a few things.


We use Elixir, node.js, webpack, and Babel.

Babel does some wonderful things like transpiling the more recent versions of ECMAScript (which support modules with `import`, and new things like async/await) down to whatever version of JS your browser supports. Including IE11, but my company doesn't support IE anymore. For example it can transpile an async/await down to a "switch/case" based event-handler.


Babel can also be a pain in the ass. Had to add an exclude rule to disable Babel on the Orion bundle in order to get webpack to load the bundle.


Generally you have to disable Babel on dist bundles, apparently, including everything under node_modules[5~/

[#] Tue Dec 29 2020 19:16:04 EST from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

Generally you have to disable Babel on dist bundles, apparently,
including everything under node_modules [5~/

I think this is because dist bundles have generally already been transpiled down to lowest-common-denominator browser JS, with some sort of CommonJS/AMD hybrid module loading convention. So you don't want to try to transpile them *again*... that way lies insanity.

There are so many JS module standards to choose from. Here's a list/doc that just scratches the surface:

https://requirejs.org/docs/whyamd.html

alt.javascript.die.die.die

[#] Wed Dec 30 2020 20:35:44 EST from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

In that article he uses the phrase "ever marching to the right callbacks".  That's exactly the problem.  When you get tied up in this async stuff ... well, the fetch/await stuff does make it easier to set up an XHR but it still only makes sense if you're reacting to an event (such as input from the user) and something happens in response.  God help you if you have to come back down the callstack and then do something afterwards.

A pox upon the house of whoever decided to deprecate synchronous XHR.  Sometimes it just makes sense.  Sometimes you're ok sitting there and blocking, because the program isn't going to do anything useful until that transaction completes.

Thankfully I have lately been in a mood of "use the tool the way it was intended, don't bastardize it to match some other way of working that you had in mind."



[#] Thu Dec 31 2020 11:22:25 EST from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


there are definitely problems with blocking the browser event loop though

Go to page: First ... 38 39 40 41 [42]