I really like using the fetch API packaged in evergreen browsers, but
I was getting annoyed with having to set the credentials, redirect, and
method options all the time, plus it always takes a bit of code to
format the querystring correctly, plus it’s annoying to set headers and
stringify JSON objects that I want to PUT to my server. So I wrote
Kvetch. First argument is URL, which gets passed directly to fetch.
Second argument is an optional query object. This can have as many key
value pairs as you want, it just gets URIComponent encoded, joined with
&s and =s, and appended to the URL after a ‘?’ (so don’t put the ?
in yourself). Third argument is the Body a.k.a. Request Payload. It can
be an object, a string, an ArrayBuffer (ie Binary data) or FormData.
A lot of people use axios, request, or other libraries on npm, but I
didn’t want to add extra features and a bunch of dependencies, I just
wanted to prevent repeating myself using the native API.
If you need it to work on browsers without fetch, just bring in some fetch polyfill and define that first, kvetch will use window.fetch just fine.
You can leave the QueryObject and the Body blank if you don’t need them.
You can pass a falsey argument (null, undefined, etc) as a QueryObject if you only need a Body.
If you give an Object as a Body, it will be JSON stringified and sent with an application/json
ContentType. If you send FormData (including files), the body is handed
directly to fetch and it figures out what to do. If you pass a string,
it will be sent untouched with a ContentType of text/plain. ArrayBuffers get sent with application/octet-stream but I haven’t actually tested this and don’t know if it’s appropriate.
At this point you should have two files, a server.js and an index.html sitting in the same directory.
For this part, we’ll just be working with index.html, so you could simply point your web browser to C:/your/file/path/index.html and it will work fine, but why not get in the habit of starting your node server? You’ll see changes to index.html reflected when you refresh the page either way.
Use the “Inspect element” to find out how Chrome interpreted our 4 lines of HTML:
Our file only contained <h1> tags and the <script> tags. <html>,<head>, <body>, and this mysterious “#shadow-root” were all added by the web browser before rendering. On top of that, in the bottom-center there’s styling added on to the <h1> element: all of this display: block; font-size: 2em; -webkit-margin-before etc. is added by Chrome to make our barebones HTML code look presentable. So like I said, you can leave a lot out and modern web browsers will figure out how to render your page anyway.
Here, ‘onclick’ listens to that ‘myButton’ element, ready to react to a click at any moment. This is different than, for instance, programming an Arduino, where we’d have to check whether a button is pressed continuously in an infinite loop. Instead, we can write a function that executes only in response to the web browser noticing that the user clicked their mouse while hovering over the button element. This is “Event driven programming.” (You actually can do event driven programming with Arduino, if you know about hardware interrupts.)
While chaining those identifiers and functions all together on one line works OK, programming like that quickly gets hard to read. It’s much better practice to break it into pieces.
Create a variable called button and assign it the myButton element.
Create a function called speak, which calls on the alert function to say hi.
Attach the ‘onclick’ event listener to the button variable and assign the function named ‘speak’ as its action.
By the way, you don’t have to have a button element to be able to click on it. I like the look of h1 better, so I’ll just click on those. I’ll change the color style of the h1 elements with each click as well. (side effect: button elements default to a block-inline style whereas header elements default to block style)
Note: “Handling Events” recommends using ‘addEventListener’ instead of ‘onclick’, which is a better way to do it. Onclick events are limited to one-per-element, whereas you can ‘addEventListeners’ as much as you want. But for a simple example I like the syntax of .onclick better.