brianvaughn

Thank you for elaborating.

Glad the tutorial is helpful! :)

It was a last minute idea and I'm excited about how it turned out.

That's definitely not the intent.

It's a little scary to upload a completely new version, when you know there's that many weekly active users that are going to be hammering away on it soon.

but Facebook is the last company I'd want to have the obscene privileges that extensions have. reply

Sounds like you're talking about extensions in general, but for what it's worth- React DevTools doesn't require any super deep permissions¹ and all of the source code is in the open².

¹ https://github.com/bvaughn/react-devtools-experimental/blob/...

² https://github.com/bvaughn/react-devtools-experimental/tree/...

You might still check out DevTools at some point :) They do a lot of small things that can be nice.

Doesn't sound like it. React DevTools uses the `postMessage` API to communicate, not websockets.

Sunil has also worked at Yahoo on maps.yahoo.com, specifically on tooling to manage styling.

s everybody knows about the implicit context(s) that also affect component behavior.

Just in case there's any misunderstanding- (I don't think there is, but just being safe)- context isn't implicit. You have to opt into it either by using the `<Consumer>` component or a HOC that injects a context prop.

Yes, but then that prop would need to be passed down explicitly through every component. This would require a _lot_ of boilerplate.

In your experience, what are the kind of things that people do in `componentWillMount` that they shouldn't be doing?

The biggest one is probably adding event listeners or setting up subscriptions (which can cause memory leaks).

Here are some others: https://github.com/reactjs/rfcs/blob/master/text/0006-static...

Is it correct to say that `getSnapshotBeforeUpdate` is named to indicate what you were supposed to use `componentWillMount` for?

No. `getSnapshotBeforeUpdate` is not really related to `componentWillMount`. It relates more to what people were using `componentWillUpdate` for.

I'm not sure why you would need to upgrade your app in that case. Is the problem that our documentation only reflects the latest release?

Upgrading any project after 3 years of inactivity would be difficult, regardless of framework.

I did not mean to imply that you would need to step through every minor version though. I was just saying that- if you were using e.g. 15, update to the latest 15 release (15.6.2) and fixing warnings in it before updating to 16.

Well, I tend to make a lot of very small stateless components. If a component is 1-6 JSX tags, the new context API represents a boilerplate overhead of between 100 and ~17%.

Not if you use a HOC (e.g. `withContext(Component)`) like a couple of the docs examples showed.

Additionally, the semantics of having a consumer's props.children be an immediately invoked function are a little bit unintuitive to me.

That's fair! I would encourage you to give it a chance though. I think it's a pattern that really grows on you after a short time. :)

I'm curious why the theme example I mentioned in my earlier comment- (and showed in the docs)- doesn't qualify as "useful" to you. Another example would be using context to share the selected language/locale between all of the localized components in an application.

I guess I should start using componentDidUpdate instead?

Sounds like it, based on your description!

The other case of componentWillReceiveProps usage I see is where there is computationally expensive derived state, but for some reason the asynchronous nature of setState prevented it from being used, and an instance variable "had" to be used instead.

`setState` calls made from within `componentWillReceiveProps` are processed (synchronously) before `componentWillUpdate` or `render` are called.

Lifecycles aren't mandatory in React. Pure functional components don't use them. Stateful class components don't necessarily need them either (although they _can_ be useful, particularly when interfacing with imperative APIs like the DOM).

I've never used Hyperdom, so this isn't meant as a criticism or commentary on it.

I don't think we know enough about where compilation will end up to comment much. I wouldn't expect TypeScript to be negatively affected though (since it compiles to JavaScript). So far, the problems we're noticing are from certain coding patterns or practices within components. However we deal with these (whether we add new lifecycles or encourage alternate patterns, etc) it should hopefully apply equally to JS/Flow/TypeScript.

The `withTheme` HOC uses `createContext` and `forwardRef`. I don't think it's contrived. :)

https://reactjs.org/blog/2018/03/29/react-v-16-3.html#forwar...

From the outside, having seen Fiber slated for release in 16.0.0 and, being pushed back to an unknown 16.x release, and then being pushed back to 17.0.0, it seems like you had not anticipated the extent to which the core React API had to be changed to enable the async renderer.

"fiber" was the code name for the rewrite that was released as version 16. Async rendering is a feature that we've been working on adding- (which the "fiber" rewrite was done to support). We've known that would take some time, mostly due to the fact that we want to gradually migrate old apps (as much as possible). :)

We're also working on other cool, related efforts- like a compiler (https://twitter.com/trueadm/status/944908776896978946) and proper built-in support for async-data, dubbed "suspense" (https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...).

However, the amount of large internal changes indicates that as you improve and (most likely) shed unneeded complexity, that there must have been complexity to shed.

The v16 rewrite (dubbed "fiber") wasn't just about cleaning up internals- it was about supporting a fundamentally different type of behavior- asynchronous rendering [1]

Obviously no one is perfect, and hindsight is 20/20, but for such a "small" (yes, interacting with the dom is actually super duper hard, and edgecases abound) scope, I've seen more large-ish overhauls than I am comfortable with.

To be fair, React supports many more targets than just the DOM. In addition to the DOM- there's react-native, react-art, react-music, react-hardware, etc.

Don't mean to sound argumentative, just wanted to add some info in case there were potential misconceptions. :)

1: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...

No, but you could do it in a similar way as the "Dynamic Context" example [1] - store the authenticated user/status in component `state` and pass it down via a AuthenticationContext.Provider. Then anything that needs to know about it could use the AuthenticationContext.Consumer.

1: https://reactjs.org/docs/context.html#dynamic-context

Our upgrade process is very gradual. As long as you've fixed all of the dev warnings for the last minor release of a given version, you should be able to upgrade to the next major without any problem.

Would you elaborate on what you find clunky about the new context API? :)

The purpose of componentWillReceiveProps was to update state in response to props changes. (This is also the purpose of getDerivedStateFromProps.)

What you're describing sounds more like you're updating something external (e.g. your Redux store). This isn't what the lifecycle is meant for, and you'd be better off using componentDidUpdate instead.

HOCs are widely used (and for good reason– they can be very useful). Hopefully forwardRef will make their usage more consistent and predictable.

If anything, I think the new context API (and even forwardRef itself) are endorsements of the render prop pattern more than of HOCs. :)

We are trying to strike a balance between supporting huge legacy apps that cannot be rewritten- (something Facebook has a lot of)- and encouraging safe/bug-free coding practices for future apps. In this case, we felt the right balance was to preserve legacy functionality while using a name that would hopefully discourage new usage (so as to avoid the potential pitfalls inherent in the legacy API).

And we provided a codemod to help with the "huge legacy apps": https://github.com/reactjs/react-codemod#rename-unsafe-lifec...

We've run it internally already to update ~14,000 components.

One of the main focuses of 16.3 is to enable open source libraries to update their code in advance of deprecation warnings. (We're trying to go one step beyond SEMVER- so that application developers don't have to be bothered by warnings in third party code that they can't change.)

And the codemod has already been released: https://github.com/reactjs/react-codemod#rename-unsafe-lifec...

We've used it internally (at Facebook) to update ~14,000 components already, so it's well tested.

This was implied but not explicitly covered in the blog post. I updated it this morning to be more explicit [1]!

You may notice in the example above that props.currentRow is mirrored in state (as state.lastRow). This enables getDerivedStateFromProps to access the previous props value in the same way as is done in componentWillReceiveProps.

You may wonder why we don’t just pass previous props as a parameter to getDerivedStateFromProps. We considered this option when designing the API, but ultimately decided against it for two reasons:

* A prevProps parameter would be null the first time getDerivedStateFromProps was called (after instantiation), requiring an if-not-null check to be added any time prevProps was accessed.

* Not passing the previous props to this function is a step toward freeing up memory in future versions of React. (If React does not need to pass previous props to lifecycles, then it does not need to keep the previous props object in memory.)

1: https://reactjs.org/blog/2018/03/27/update-on-async-renderin...

You will be able to continue to use this method in version 17. You'll just need to run a codemod [1] to rename it to "UNSAFE_ componentWillReceiveProps". It will otherwise work the same as it always has.

We are trying to strike a balance between supporting huge legacy apps- (something Facebook has to do for itself too)- and encouraging safe/bug-free coding practices for future apps.

1: https://github.com/reactjs/rfcs/blob/master/text/0006-static...