Stoyan Stefanov

Bear Bibeault wrote:
..."trust" (maybe not quite the right word) the longevity of the transpiled languages

I am with you when it comes to CoffeeScript, etc. But what about transpilers that just work with ES6 and beyond, e.g. Babel, transpiling new standard syntax of the language, or almost-certainly-standard-to-be?

I admit I found it awkward at the beginning to use stuff like arrow functions, but now having to type function all the time feels... so... boring

You can also look into Flow (http://flowtype.org) as an addition to modern ECMAScript that does types for you. You opt-in so you can start adding types to your individual files (modules) one at a time. Pretty amazing what JS looks like these days.

From the TOC it looks like ES6 is heavily represented. Are there any ES6 (or beyond) features that you left out as they are probably not great or are underdeveloped? The ones that *are* represented - did you aim for giving ES6 justice (and describe all features) or just the ones that you recommend a ninja should master.

Does the reader need to have read the previous edition before moving on to ES6 stuff?

What's your view on compiling/transpiling JavaScript, can a modern day developer still write plain JS or it's a thing of the past?

Thanks for the Q&A!

Congrats to the winners Bhushan, Amandeep, Zita and Bear!

And thanks everyone for the questions, it was fun!

Bear Bibeault wrote:So what is generally used to provide the M and C? Is there a consensus, or is it every dev for themselves?

Flux helps Or M is just a JS object, C is whatever.

Bear Bibeault wrote:"what do you think is the part that's most essential?"

If there's one thing... that is not to be scared of all the options out there (WebPack, Redux, Reflux, Grunt, Gulp, bla, blah). You can DIY, it's simple.

yeah, I shied away from generators completely

gah, something happened with the second and third code snippets. I meant

<BB height="tall">

and

<BB ifyouclick="myonclick" ifyouhover="myonhoverhandler" ...>


(I think < B > is throwing things off so I changed to <BB>)

So you've built an app composing a number of components. A is the overall App, B is Body component, C is Cool component inside B, ... F is Footer component - a sibling to B.

<A>  <B>    <C />  </B>  <F /> </A>

A can configure B and F using properties, e.g.

<A>  <B >

If A changes its mind because something happens in the app, it can reconfigure B (and React takes care of the most efficient way to do so without disrupting anything, say person typing in a search box inside C)

But what if B experiences a change that A should know about? One way is to let A provide callbacks for every type of change

<A>  <B   ...>

But this can become verbose quickly. Also doesn't solve the problem where C wants to communicate a change to A (without passing through callbacks all the way). And definitely doesn't solve the problem of B communicating a change to F.

So you need events of some sort. Flux is an idea of how you may go about organizing those events and messages in a uni-directional sensible approach.

The idea in its simplest is - all components get their data from a Data store. And when something happens they call an Action. The Action updates the Store and all components (that care about the change) rerender with the new data in mind.



So Flux is just an idea and there are many implementations of it. Redux seems to be one of the most popular. In the book I build a simple one from scratch

exactly, fail soon, fail often, fail spectacularly

Some JS knowledge is required. But doesn't need to be latest greatest ES2016. If you know about loops and functions in JavaScript you should be fine. If you stopped writing and keeping up with JavaScript 10 years ago you should be fine. The first 3 chapters build on ancient JavaScript that has been around since IE6. Chapter 4 adds React-specific syntax (JSX). From there new JS features (some not even in the browsers yet) are introduced.

In way the book can help you catch up with JS if you've been under a rock for a while

Bear Bibeault wrote:Does it update frequently? Is there a commitment to backwards compatibility between versions?

Yes and yes. Deprecated APIs bring a console warning for a few versions before they disappear completely.

And, version 15?

15 was sorta major-ish and I hope there's nothing major coming in foreseeable future

There was a versioning scheme change so v15.0.0. was the version after v0.14.4. which was kinda funny.

Bear Bibeault wrote:Do you find this imposes an undue burden on run-time debugging?

Not really, JSX transform preserves line #s, there are also source maps. Plus if you make a typo you figure out this immediately because the transform fails

Enrique M. Talavera wrote:Thanks for your reply, so with this tool it should be considered old-fashioned the old naked HTML? It looks like the creation of the DOM it's preferable to be used within the JSX code.
Best Regards

Yes, React takes over the trouble of you fiddling with the DOM. Which is nice because DOM creation/update is:

verbose

slow

React fights the slowness by creating an internal representation of what you want the DOM to be (also known as "virtual DOM" and implemented as a simple JS object) than translating the virtual DOM to real DOM nodes using as little createElement/appendChild/etc as possible. Then when the data in the app changes, React figures out the diff between what you want the DOM to be, compared to what it was before, and then updates the DOM in the most efficient way possible.

You never really need to touch the DOM yourself, but you can, there's an "escape latch" that gives you the underlying DOM nodes if you need them.

The biggest benefit I see is that in the old-style DOM manipulation you end up hunting for DOM nodes to update all the time. Often most of your "onclick" handler is looking for nodes. jQuery helps reduce the verbosity of the hunt, but the hunt is still there. With React, the hunt is over. You just update the data (state, which is also just a JS object) and the UI is magically rebuilt

BTW, the idea of the virtual DOM is now well regarded, adopted in Angular 2, and many think should be part of the browsers' API

Bear Bibeault wrote:... building up UI in strings in code is anathema to me...

Sure. Any string concatenation is a red flag

However JSX is not it. You cannot do

var whatevs = '<MyComponent' + ' />';

You can only go

var whatevs = <MyComponent />;


(Which is not valid JS so you need a transform.)

But, as I said, this is optional. You can also not use any JSX and just use function calls to declare the components

var whatevs = React.createElement(Component);

Then compose and customize:

var whatevs = React.createElement(  MyComponent,  { name: "Bob" },  React.createElement("head", null),  React.createElement("body", null),  React.createElement("legs", { count: "2" }) );

Using JSX makes this a little more readable..

var whatevs =  <MyComponent name="Bob">    <head />    <body />    <legs count="2" />  </MyComponent>;