You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 21_skillsharing.md
+9-15Lines changed: 9 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -274,15 +274,15 @@ This uses a similar convention as the file server from the [previous chapter](no
274
274
275
275
The ((talk))s that have been proposed are stored in the `talks` property of the server, an object whose property names are the talk titles. These will be exposed as HTTP ((resource))s under `/talks/[title]`, so we need to add handlers to our router that implement the various methods that clients can use to work with them.
276
276
277
-
{{index "GET method", "404 (HTTP status code)"}}
277
+
{{index "GET method", "404 (HTTP status code)" "hasOwn function"}}
278
278
279
279
The handler for requests that `GET` a single talk must look up the talk and respond either with the talk's JSON data or with a 404 error response.
That concludes the server code. If we create an instance of `SkillShareServer` and start it on port 8000, the resulting HTTP server serves files from the `public` subdirectory alongside a talk-managing interface under the `/talks` URL.
new SkillShareServer(Object.create(null)).start(8000);
469
+
new SkillShareServer({}).start(8000);
472
470
```
473
471
474
472
## The client
@@ -809,14 +807,10 @@ Extend the server so that it stores the talk data to disk and automatically relo
809
807
810
808
The simplest solution I can come up with is to encode the whole `talks` object as ((JSON)) and dump it to a file with `writeFile`. There is already a method (`updated`) that is called every time the server's data changes. It can be extended to write the new data to disk.
Pick a ((file))name, for example `./talks.json`. When the server starts, it can try to read that file with `readFile`, and if that succeeds, the server can use the file's contents as its starting data.
815
813
816
-
{{index prototype, "JSON.parse function"}}
817
-
818
-
Beware, though. The `talks` object started as a prototype-less object so that the `in` operator could reliably be 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.
819
-
820
814
hint}}
821
815
822
816
### Comment field resets
@@ -831,7 +825,7 @@ In a heated discussion, where multiple people are adding comments at the same ti
831
825
832
826
{{index "comment field reset (exercise)", template, "syncState method"}}
833
827
834
-
The best way to do this is probably to make talks component objects, with a `syncState` method, so that they can be updated to show a modified version of the talk. During normal operation, the only way a talk can be changed is by adding more comments, so the `syncState` method can be relatively simple.
828
+
The best way to do this is probably to make the talk component an object, with a `syncState` method, so that they can be updated to show a modified version of the talk. During normal operation, the only way a talk can be changed is by adding more comments, so the `syncState` method can be relatively simple.
835
829
836
830
The difficult part is that, when a changed list of talks comes in, we have to reconcile the existing list of DOM components with the talks on the new list—deleting components whose talk was deleted and updating components whose talk changed.
0 commit comments