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².
> 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.
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.
> 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). :)