Merge pull request mjavascript#6 from arackaf/feature/chapter5-feedback

Chapter 5 tweaks

Author: bevacqua

chapters/ch05.asciidoc

@@ -77,7 +77,52 @@ const {
 } = response
 ----
 
-One contention point might be that, at times, the deeply destructured property name doesn't make sense outside of its context. For instance, we've introduce `name` to our scope, but it's the name of the contact for the listing, not to be confused with the name of the listing itself. In these cases, the alternative may be to give `response.contact.name` an alias where we add the parent property name as a prefix, so that we're left with a binding named `contactName` or `responseContactName`.
+At times, a deeply destructured property name may not make sense outside of its context. For instance, we introduce `name` to our scope, but it's the name of the contact for the listing, not to be confused with the name of the listing itself. We can clarify this by giving the contact's `name` an alias, like `contactName` or `responseContactName`.
+
+[source,javascript]
+----
+const {
+  title,
+  description,
+  askingPrice,
+  features: {
+    area,
+    bathrooms,
+    bedrooms,
+    amenities
+  },
+  contact: {
+    name: responseContactName,
+    phone,
+    email
+  }
+} = response
+----
+
+When using `:` to alias, it can be difficult at first to remember whether the original name, or the aliased name comes first. One helpful way to keep this straight is to mentally replace `:` with the word "as."  So `name: responseContactName` would read as "name as responseContactName." 
+
+We can even have the same property listed twice, if we wanted to destructure some of its contents, while also maintaining access to the object itself.  For example, if we wanted to destructure the `contact` object's contents, like we do above, but also take a reference to the whole `contact` object, we can do the following
+
+[source,javascript]
+----
+const {
+  title,
+  description,
+  askingPrice,
+  features: {
+    area,
+    bathrooms,
+    bedrooms,
+    amenities
+  },
+  contact: responseContact,
+  contact: {
+    name: responseContactName,
+    phone,
+    email
+  }
+} = response
+----
 
 Object spread helps us create a shallow copy of an object using a little native syntax. We can also combine object spread with our own properties, so that we create a copy that also overwrites the values in the original object we're spreading.
 
@@ -146,6 +191,16 @@ const finalValues = doubledValues.filter(value => value > 5)
 // <- [6, 8, 10]
 ----
 
+NOTE - this doesn't make sense.  The original example assigned to the SAME variable over and over again.  Wouldn't the simplified, equivalent code just chain the subsequent calls?
+
+[source,javascript]
+----
+let values = [1, 2, 3, 4, 5]
+  .map(value => value * 2)
+  .filter(value => value > 5)
+// <- [6, 8, 10]
+----
+
 Let's move onto a more interesting topic: asynchronous code flows.
 
 ==== 5.1.4 Navigating Callbacks, Promises, and Asynchronous Functions
@@ -435,7 +490,26 @@ Having event listeners allowed a component to receive a message, perhaps process
 
 ==== 5.3.4 Message Passing and the Simplicity of JSON
 
-When it comes to ServiceWorker, web workers, browser extensions, frames, API calls, or WebSocket integrations, we might run into issues if we don't plan for robust data serialization ahead of time. This is generally when using classes to represent data starts to breaks down, because we'd need a way to serialize instances into their raw data counterparts (typically JSON) before sending it over the wire, since the receiving end wouldn't know how to decode a JavaScript class instance, and there isn't a standardized way of encoding them either. At the same time, we'd need a way to deserialize this plain JSON data on the receiving end, creating another class instance making sure it has the correct state.
+When it comes to ServiceWorker, web workers, browser extensions, frames, API calls, or WebSocket integrations, we might run into issues if we don't plan for robust data serialization ahead of time. This is a place where using classes to represent data can break down, because we need a way to serialize class instances into raw data (typically JSON) before sending over the wire, and, crucially, the recipient needs to decode this JSON back into a class instance. It's the second part where classes start to fail, since there isn't a standardized way of reconstructing a class instance from JSON. For example
+
+[source,javascript]
+----
+class Person{
+  constructor(name, address){
+    this.name = name;
+    this.address = address;
+  }
+  speak(){
+    alert(`My name is ${this.name}`);
+  }
+}
+
+let nico = new Person("Nico", "123 Main St");
+----
+
+Although we can easily serialize our `nico` instance with `JSON.stringify(nico);`, and then send it over the wire, the code on the other end will have no standard way of turning this JSON back into an instance of our `Person` class.
+
+NOTE: then again, can you clarify why the receiving end would need to deserialize the data back into class instances, rather than just use raw object literals?  Assymetric representations of the same data is likely uglfy, and needlessly complex, and so possibly the only reason, and a good one, but it might be worth spelling out explicitly.
 
 JSON, a subset of the JavaScript grammar, was purpose-built for this use case, where we often have to serialize data, send it over the wire, and deserialize it on the other end. Plain JavaScript objects are a great way to store data in our applications, offer frictionless serialization out the box, and lead to cleaner data structures because we can keep logic decoupled from the data.