Question

Disk persistence

The simplest solution I can come up with is to encode the whole talks object as JSON and dump it to a file with fs.writeFile . There is already a function ( registerChange ) that is called every time the server’s data changes. It can be extended to write the new data to disk.

Pick a filename, for example ./talks.json . When the server starts, it can try to read that file with fs.readFile , and if that succeeds, the server can use the file’s contents as its starting data.

Beware, though. The talks object started as a prototype-less object so that the in operator could be sanely used. JSON.parse will return regular objects with Object.prototype as their prototype. If you use JSON as your file format, you’ll have to copy the properties of the object returned by JSON.parse into a new, prototype-less object.

Comment field resets

The ad hoc approach is to simply store the state of a talk’s comment field (its content and whether it is focused) before redrawing the talk and then reset the field to its old state afterward.

Another solution would be to not simply replace the old DOM structure with the new one but recursively compare them, node by node, and update only the parts that actually changed. This is a lot harder to implement, but it’s more general and continues working even if we add another text field.

Better templates

You could change instantiateTemplate so that its inner function takes not just a node but also a current context as an argument. You can then, when looping over a node’s child nodes, check whether the child has a template-repeat attribute. If it does, don’t instantiate it once but instead loop over the array indicated by the attribute’s value and instantiate it once for every element in the array, passing the current array element as context.

Conditionals can be implemented in a similar way, with attributes called, for example, template-when and template-unless , which cause a node to be instantiated only when a given property is true (or false).

The unscriptables

Two central aspects of the approach taken in this chapter—a clean HTTP interface and client-side template rendering—don’t work without JavaScript. Normal HTML forms can send GET and POST requests but not PUT or DELETE requests and can send their data only to a fixed URL.

Thus, the server would have to be revised to accept comments, new talks, and deleted talks through POST requests, whose bodies aren’t JSON but rather use the URL-encoded format that HTML forms use (see Chapter 17 ). These requests would have to return the full new page so that users see the new state of the site after they make a change. This would not be too hard to engineer and could be implemented alongside the “clean” HTTP interface.

The code for rendering talks would have to be duplicated on the server. The index.html file, rather than being a static file, would have to be generated dynamically by adding a handler for it to the router. That way, it already includes the current talks and comments when it gets served.

This is a book about getting computers to do what you want them to do. Computers are about as common as screwdrivers today, but they contain a lot more hidden complexity and thus are harder to operate and understand. To many, they remain alien, slightly threatening things.