current proposed talks and their comments. Whenever someone,

somewhere, submits a new talk or adds a comment, all people who have

the page open in their browsers should immediately see the change.

open a connection to a client, nor is there a good way to know which

{{index "Node.js"}}

To be able to immediately notify a client that something changed, we

need a ((connection)) to that client. Since web ((browser))s do not

We can arrange for the client to open the connection and keep it

around so that the server can use it to send information when it needs

to do so.

But an ((HTTP)) request allows only a simple flow of information: the

client sends a request, the server comes back with a single response,

and that is it. There is a technology called _((web sockets))_,

supported by modern browsers, which makes it possible to open

((connection))s for arbitrary data exchange. But using them properly

is somewhat tricky.

{{index "live view"}}

application open in her browser, that browser will have made a request

for updates and be waiting for a response to that request. When Iman

submits a talk on Extreme Downhill Unicycling, the server will notice

{{index robustness, timeout}}

To prevent connections from timing out (being aborted because of a

time for each request, after which the server will respond anyway,

{{index "Node.js"}}

{{index [path, URL]}}

{{index "GET method"}}

_((conditional request))_ by including an `If-None-Match` header whose

value holds that same string. If the resource hasn't changed, the

server will respond with status code 304, which means "not modified",

{{index "Prefer header"}}

which tells the server that the client is willing wait up to 90

seconds for the response.

requests like this to be notified when the talks change:

```{lang: null}

{{index "skill-sharing project"}}

code in this section runs on ((Node.js)).

`/^\/talks\/([^\/]+)$/` (`/talks/` followed by a talk title) can be

handled by a given function. In addition, it can help extract the

meaningful parts of the path, in this case the talk title, wrapped in

handler function.

{{index "require function", "Router class", module}}

This uses a similar convention as the file server from the [previous

chapter](node) for responses—handlers return promises that resolve to

{{index "long polling", "updated method"}}

about the change.

To retrieve the content of a request body, we define a function called

```{includeCode: ">code/skillsharing/skillsharing_server.js"}

which is used to create new ((talk))s. It has to check whether the

data it was given has `presenter` and `summary` properties which are

strings. Any data coming from outside the system might be nonsense,

{{index "updated method"}}

Trying to add a comment to a nonexistent talk returns a 404 error.

The most interesting aspect of the server is the part that handles

{{index "talkResponse method", "ETag header"}}

the `Prefer` header to see if we should delay the response or respond

right away.

`waiting` array, so that they can be notified when something happens.

The `waitForChanges` method also immediately sets a timer to respond

```{includeCode: ">code/skillsharing/skillsharing_server.js"}

{{id updated}}

```{includeCode: ">code/skillsharing/skillsharing_server.js"}

{{index "skill-sharing project"}}

three files: a tiny HTML page, a style sheet, and a JavaScript file.

which defines a few styles to, among other things, make sure there is

some space between talks.

The `handleAction` function takes such an action and makes it happen.

Because our state updates are so simple, state changes are handled in

```{includeCode: ">code/skillsharing/public/skillsharing_client.js", test: no}

{{index "talkURL function", "encodeURIComponent function"}}

```{includeCode: ">code/skillsharing/public/skillsharing_client.js", test: no}

We'll use an approach similar to the one we saw in [Chapter ?](paint),

splitting the application into components. But since some of the

directly return a DOM node. For example, here is a component that

shows the field where the user can enter their name:

{{index "elt function"}}

```{includeCode: ">code/skillsharing/public/skillsharing_client.js", test: no, hidden: true}

{{index "pollTalks function", "long polling", "If-None-Match header", "Prefer header", "fetch function"}}

load is closely related to the long polling process—the `ETag` from

the load must be used when polling—we'll write a function that keeps

polling the server for `/talks`, and calls a ((callback function))

{{index "async function"}}

retrieves the list of talks—either normally or, if this isn't the

first request, with the headers included that make it a long polling

request.

{{index synchronization, "live view"}}

When the talks change, this component redraws all of them. This is

We can start the application like this:

The following exercises will involve modifying the system defined in

this chapter. To work on them, make sure you ((download)) the code

first

function maybeSplitInlineCode(html) {

if (html.length <= 16) return html

function anchor(token) {