Javascript

I’m in the process of figuring out pointer events after originally doing the games for mouse events.

Add the event handlers to a specific target element (rather than the entire document or nodes higher up in the document tree). — Best Practices

This means add listeners to canvas rather than document?

Pointer Capture

function downHandler(ev) {
  const el = document.getElementById("target");
  // Element "target" will receive/capture further events
  el.setPointerCapture(ev.pointerId);
}

function cancelHandler(ev) {
  const el = document.getElementById("target");
  // Release the pointer capture
  el.releasePointerCapture(ev.pointerId);
}

function init() {
  const el = document.getElementById("target");
  // Register pointerdown and pointercancel handlers
  el.onpointerdown = downHandler;
  el.onpointercancel = cancelHandler;
}

pointercancel event

https://developer.mozilla.org/en-US/docs/Web/API/Element/gotpointercapture_event

https://developer.mozilla.org/en-US/docs/Web/API/Element/lostpointercapture_event

https://developer.mozilla.org/en-US/docs/Web/API/Element/setPointerCapture

https://developer.mozilla.org/en-US/docs/Web/API/Element/hasPointerCapture

https://developer.mozilla.org/en-US/docs/Web/API/Element/releasePointerCapture

https://developer.mozilla.org/en-US/docs/Web/CSS/CSSOM_view/Coordinate_systems

e.clientX

Modules

Many things confused me about JavaScript’s modules, and there appear to be many quirks, especially regarding scoping.

Declaration

The modern way is to load a main.js file in the head of an HTML document with the attribute type="module":

<head>
...
  <script type="module" src="/js/main.js"></script>
</head>

This replaces the old way of loading the file before the closing </body> to ensure the DOM objects used by the JavaScript code were known to it. Something that tripped me up is the type="module" attribute means main.js is a module client, aka importer, not an exporter, ie what’s generally thought of as a module.

jsdoc

To install, as root:

npm install -g jsdoc

Google JavaScript Style Guide

jsdoc -d doc -r js -R js/README.md

Website

Github

jasmine

Documentation

First off, we need an html file to load the files required by Jasmine along with the file containing our tests as a module client.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Jasmine Spec</title>

  <link rel="shortcut icon" type="image/png" href="/jasmine/images/jasmine_favicon.png">
  <link rel="stylesheet" href="/jasmine/lib/jasmine-core/jasmine.css">

  <script src="/jasmine/lib/jasmine-core/jasmine.js"></script>
  <script src="/jasmine/lib/jasmine-core/jasmine-html.js"></script>
  <script src="/jasmine/lib/jasmine-core/boot0.js"></script>
  <!-- optional: include a file here that configures the Jasmine env -->
  <script src="/jasmine/lib/jasmine-core/boot1.js"></script>
  <script type="module" src="eg1.js"></script>
</head>

<body>
</body>
</html>

git clone https://github.com/jasmine/jasmine.git

The key files are in jasmine/lib/jasmine-core.

node

After gaining some experience at using Bash’s associative arrays to handle JSON, I decided a better approach would be to rather write Unix filters in JavaScript which read JSON from stdin and write the munged JSON to stdout while logging problems to stderr.

Courtesy of node, that can be done, though it required deciphering its jargon. For instance what I’d call a remote procedure call to, say, date, involves using Node’s child_process module.

As a first exercise, let’s rewrite the bash function below:

Frontier Software