getify / Functional-Light-JS

Pragmatic, balanced FP in JavaScript. @FLJSBook on twitter.
http://FLJSBook.com
Other
16.6k stars 1.96k forks source link

Copyediting suggestions for Chapter 9 #129

Closed jtassia closed 6 years ago

jtassia commented 6 years ago

Chapter 9 suggestions/queries...

Edit suggestion 1

Original: "It's important to note that we're not talking about mapping transformation as implying in-place mutation or reassignment; rather mapping transformation projects a new value from one location to the other."

Suggestion: "It's important to note that we're not talking about mapping transformation as implying in-place mutation or reassignment; instead, we're looking at how mapping transformation projects a new value from one location to the other."

Edit suggestion 2

Original: "If you think of true as being as a positive signal, the..."

Suggestion: "If you think of true as indicating a positive signal, the..."

Edit suggestion 3

Original: "We're cheating with this reducer and allowing a side effect by allowing..."

Suggestion: "We're cheating with this reducer and introducing a side effect by allowing..."

Edit suggestion 4

Original: "From time to time, you may have (or produce through some other operations) an array that's not just a flat list of values, but with nested arrays, such as:"

Suggestion: "From time to time, you may have (or produce through some other operations) an array that's not just a flat list of values -- for instance, it might include nested arrays, as shown here:"

Edit suggestion 5

Original: "What if you'd like to transform it into:"

Suggestion: "What if you'd like to transform it as follows?"

Edit suggestion 6

Original: "As you roll FP list operations into more of your thinking about code, you'll likely start seeing very quickly chains that combine behavior like:"

Suggestion: "As FP list operations become more fully incorporated into the way you think about code, you'll likely very quickly begin to recognize chains that combine behavior like:"

Query 1

Original: some(..) and every(..) do encourage the use of pure functions (specifically, predicate functions like filter(..) does), but

Query: Should "does" be deleted here?

Yes, I promise I've read the Contributions Guidelines

getify commented 6 years ago

Suggestion: "It's important to note that we're not talking about mapping transformation as implying in-place mutation or reassignment; instead, we're looking at how mapping transformation projects a new value from one location to the other."

Great!

Suggestion: "If you think of true as indicating a positive signal, the..."

Great!

Suggestion: "We're cheating with this reducer and introducing a side effect by allowing..."

How about: "We're cheating with this reducer: using a side effect by allowing..."

Suggestion: "From time to time, you may have (or produce through some other operations) an array that's not just a flat list of values -- for instance, it might include nested arrays, as shown here:"

Great!

Suggestion: "What if you'd like to transform it as follows?"

Great!

Suggestion: "As FP list operations become more fully incorporated into the way you think about code, you'll likely very quickly begin to recognize chains that combine behavior like:"

How about: "As FP list operations permeate the way you think about code, you'll very likely start recognizing chains of behavior that can be combined, like:"

Query: Should "does" be deleted here?

filter(..) isn't the predicate, it expects predicates. So, "does" needs to be there, or it needs to be reworded to something like "expects".

jtassia commented 6 years ago

Done!