Due: 2017-03-23 11:00a
For version three, you will start talking to a server using a REST interface. Just as we did with the Film Explorer, you will transfer over to letting a server maintain the state.
I have again provided you with solution code on Canvas that you should use as your starting point.
I initially provided you with the Map to give you experience using the data structure and to make it a little easier to reason about sections (though when all is said and done, I suspect some of you did not find it easier…).
We want to add the collection to the state of the ContentArea container component and make it a little easier to tear apart for our server interactions. As such, I want you to throw away the Map, and leave the data as a flat Array. You should instead, load it into the ContentArea's state.
This will require you to rethink how the IndexBar uses its collection prop. Do not worry about handleEditorReturn just yet (so editing will temporarily be broken). Just get browsing working again with the collection as an Array stored in state.
Just as we did with the Film Explorer, switch from getting the data from the local copy and instead fetch it from the server (details to follow).
Rewrite handleEditorReturn() so that it handles edits and additions. This will require a little bit of restructuring of the code. Currently, the only difference between an edit and an addition is that if we are editing, we delete the old version first. When using REST, updates and additions are two different functions (note that I expect you to do this properly and not just issue a `DELETE command).
As with the Film Explorer example, you will tell the server about the new/updated article, and the server should return a copy of the article back to us. You then want to add the article into the collection, removing the old one if appropriate. As the collection is now a state object, you should not modify, but replace the collection for the state change.
Next to the Edit button, add a Delete button that deletes the current article. All of the caveats about communicating with the server and updating the state apply here as well. Write a new instance method on the ContainerArea to handle this.
You will be communicating with a server running on basin at http://basin.cs.middlebury.edu:3042. The REST interface can be found at /articles, which can be optionally followed by an id.
You will find that the articles now all have a new field called _id. You can use this when constructing your requests to the server (I also recommend adopting it for any keys you might have… such as in Titles).
As a reminder, the server protocol looks like this:
| Endpoint | Command | Action |
|---|---|---|
| /articles | GET | fetch the entire article collection as an array |
| /articles | POST | add a new article to the collection (should be included in request body) |
| /articles/:id | PUT | update the provided article (new article should be in the request body) |
| /articles/:id | DELETE | remove the indicated article |
In the case of both PUT and POST, the server will send back the new article as confirmation of success.
Note that you will now all be sharing one central data store! By all means test away, but be mindful of others (don't delete everything). I will periodically refresh the server with the seed data again, but try not to corrupt it over much (and let me know if it becomes too much of a mess).
| Points | Criteria |
|---|---|
| 5 | Code organization/ design/ comments / style |
| 5 | Conversion of collection to array |
| 5 | Loads collection from the server |
| 5 | Updates articles on the server |
| 5 | Adds articles to the server |
| 5 | Deletes articles |
To hand in your work, please make a copy of you working directory, rename the copy username_hw05, remove node_modules from it, and then zip it up. I would rather regenerate node_modules when I look at your work rather than having you submit the huge directory, so really, please don't include it.
You can then submit the zipped folder on Canvas.