Nader,

Any chance, without ruffling the feathers of the eager beavers waiting for this book to be completed, we will get a taste of using the React Native Elements UI toolkit?

Or do you have a blog post lurking in the interwebs?
I think the React ecosystem is constantly in flux with fast changes. I would rather the book be up to date and late than rushed out the door and obsolete. Let's try to understand that React is a fast moving target with the only thing being constant is change itself.

Nader Dabit, knock it out of the park bro!
In Section 2.4.1, the last paragraph states:

The first values logged out for tick is 1 and the refs as an empty object, showing us that the render method runs only after componentWillMount, but after componentDidMount.

This should rather say:

...., showing us that the render method runs after componentWillMount, but before componentDidMount.
In the code, we have:

 topics = topics.map((topic, i) => {
  return <Text>{ topic }</Text>
})


Why even have the index variable i in there as we aren't using it? Just a nitpick, nothing wrong really. But, it keeps the code a little bit cleaner by removing it.
So, I'm looking at the topic on destructuring props and state and in Listing 2.12 we have this line of code:

 const { book } = this.state 


should this rather be:

 const { book } = this.state.book 


Or is it ok to use this.state when there is only one property variable in state?
I believe the current version of React Native no longer provides index.ios.js and index.android.js after running init. Instead it only provides a index.js file.

Can this be confirmed?
By any chance, will the Animations chapter cover the Lottie library? Any mention of extracting from AE with bodymovin?

TIA!
Ethan Sherbondy wrote:Found another little typo on pg. 121, section 6.2.5. I think the author meant to refer to
supervisor/3
rather than
supervise/3
:

If you're supervising a Supervisor then use supevise/3



It's odd that supervisor/3 isn't mentioned till later on in the chapter after Pg. 121.
I think stats in the code should have been written as state. Typo that is at least used consistently throughout the code.
GenServer is a way to facilitate the communication between a client and server in a predictable and fault-tolerant way that allows you to keep and manage state. The Metex.Worker module (worker.ex) is being used by the client and the server. The client in the example is the iex shell and the server is the GenServer that is invoked by the shell with the command,
 {:ok, pid} = Metex.Worker.start_link
. This creates the separate server process from the shell/client process.

When you said that the call and cast are being done in the server, that is actually not true. The client (iex shell) has invoked the call as it is wrapped in get_temperature(pid, location). get_temperature wraps a call to GenServer.call . And Genserver.call makes a synchronous call to the server's handle_call/3.

If you get the source code from github or look at table 4.3, you will understand it better.

GenServer.start_link, GenServer.call, and Genserver.cast are Client APIs and init, handle_call, and handle_cast are Server APIs.

It's a little weird to wrap your head around at first, but try to sketch out the processes on paper and place all the relevant function calls with the appropriate process and it makes a lot of sense visually.

Hope that helps a bit.
I had this same doubt as I was reading Ch. 3 and came to get clarification. It's good to see that someone already asked this. smilie

Great book so far, btw!
This is still not corrected in the V7 MEAP.
Hi, I was reading the first chapter that is available on here and on page 3 the diagram at the bottom shows the CoreOS layout. etcd is shown as common to all nodes. But, each node has it's own etcd client so that each node can communicate with each other, correct?
Ahhh, now it makes sense. I need to understand currying a bit more and I think your explanation definitely made it much clearer.

Currying is when you take a function with multiple arguments and translate that into functions that each take a single argument.

Thanks for the quick reply. Will definitely re-read that section to make sure it sinks in.
Listing 1.4 starts with....

var find = curry(function (db,id) {

it should probably have another parenthesis as such:

var find = curry(function (db,id)) {


The same problem is found further down the same listing, where we have....

var append = curry(function (elementId, info) {

should it not be:

var append = curry(function (elementId, info)) {


And lastly, we have...

var showStudent = run (append ('#student-info'), csv, find(db));

I thought that the append requires two parameters, one being the elementId and the other being the student info. Here we are stating the elementId but leaving out the student info (csv) as part of the run parameter. I'm assuming the append will set the elementId and leave the student info blank for the run statement to fill. But, the run statement could have just as easily been written as:

var showStudent = run(append('#student-info',csv), find(db));

Am I right? Also, showStudent is passed the ssn, but the code does not show how the ssn is used by showStudent to link everything else. I understand this is more pseudo code and just an example, but there may be some confusion. Or maybe I just haven't read further ahead where the example is more fleshed out.

Please clear my doubts. And I will continue reading in the hopes that maybe I can clear my own doubts. Thanks!
The below paragraph is a bit confusing as I'm not sure where "state" is mentioned in the sample code other than in the Metex.init/1 return values.

"The first argument declares the expected request to be handled. The second argument
returns a tuple in the form of {pid, tag}, where the pid is the pid of the client, and tag
is a unique reference of the message. The third argument, state, represents the internal
state of the server."

Which code is this referring to or is there a typo?

PHP +1