Key Value Fetch with Kvetch.js

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.

kvetch.get/post/put/delete/options(URL::string[, QueryObject::Object, Body::*)

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.

Here’s the source code, you can even copy paste this into your browser console to try it out, or fork the repo here:

Voice Controlled Web Apps Pt. 2 (Windows)

NodeJS, Client Side Javascript, and Google Speech API

Part 2 in a 5 part series. Part 1 is here.

This section of the tutorial introduces “client side javascript” — running code alongside HTML in a web browser. We won’t be building a beautiful site. Instead, I’m going to introduce as little as possible to get results so you can move onto controlling lamps and motors and other internet-connected-things. Hopefully you can combine this with your own knowledge or other tutorials to build the application you want.

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.

The history of HTML is a jumbled one with many actors. Lots of people were taking stabs at building websites and lots of people were writing web browsers that did their best to render a useable website from everyone else’s code. The modern day result of this is that the web browser is a very forgiving platform that lets you leave all kinds of stuff out, and lets mistakes go without complaining too much. That’s actually one reason why I’ve heard some people discourage javascript as a first programming language: you can make a lot of mistakes and there’s not a compiler to tell you what you did wrong, the web browser will try to run anything it can and ignore whatever doesn’t work.

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.

OK, I promised an interactive web page, so let’s change that header <h1> into a button <button>. If you don’t know: in lots of text editors Ctrl+H will bring up a “find and replace” menu. We’ll also add an “id” attribute inside the opening button tag: this is a name you give individual elements so you can write javascript that acts (or listens to) those elements.

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.

  1. Create a variable called button and assign it the myButton element.
  2. Create a function called speak, which calls on the alert function to say hi.
  3. Attach the ‘onclick’ event listener to the button variable and assign the function named ‘speak’ as its action.

I included two ways you could create the speak function here that would work equivelantlly in this case. There are specific cases where you should choose one or the other that involve global vs local scope (great info on the subject here), but for now it’s just important to know that there’s more than one way to do it. Hopefully keeping that in mind will make reading other people’s javascript examples less confusing.

Buttons default to ‘block-inline’ style, and appear on the same line

Let’s move on to a button that changes the background — this will set us up for turning a lamp on and off. The buttons have separate IDs, and each button is assigned to a new javascript variable.

Header elements default to ‘block’ style and appear on separate lines

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)

In the next section, we’ll plug a lamp into an Arduino:

Recommended Reading:

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.