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².
Yeah, but the intent is to drive developers away from the building blocks of web and weaken the value of HTML standards and accessibility guidelines that make the web awesome. Evil has many masks. And a corporation powered ‘open source’ is now the worst evil monster we have had to face in decades.
To give some context. Historically React has been all about sharing what worked for us at FB for creating dynamic, complex apps. If it doesn't work well for you, please don't use it. There are plenty of alternatives.
The notion that there's some kind of plan to "weaken the web" there just isn't true. I don't know what you're basing it on. You may not remember this, but when React came out, everybody laughed at it. It was not some kind of asset for Facebook at the time. If we talk about motivation, ours is quite the opposite. We want to empower web developers to create complex UIs, comparable to native apps. We very much want the web to win, or at least to stay relevant.
The only reason React got open sourced and kept being developed in the open was because engineers working on it wanted to share it with the wider web community. They saw something useful in it. Eventually, the industry took note, but it wasn't until a few years later. We believe in open web, and this is why we work on React.
The notion that React is at odds with accessibility is also mistaken. React outputs regular DOM, and common React setups like Create React App include more accessibility checks than you'd get writing HTML by hand. Maybe you're confusing React with something else?
Yes, keeping dynamic JS apps accessible has its own set of challenges (we document some here: https://reactjs.org/docs/accessibility.html), but it's not React that makes it hard. It's the dynamic UI expected by users that makes it hard. If anything, in my experience React makes it easier for teams to adopt better accessibility practices by putting them directly into React components (example: https://ui.reach.tech).
Finally, concerning standards. We've worked and will continue working with standards committees to bring good parts of React into the platform. For example, the "object spread" operator in JavaScript was originally added to JSX, and was championed in TC39 by a React team member. Similarly, we're closely working with standard bodies to improve web app responsiveness. Not just for React, but for all libraries. You can learn more about this work here:
> We want to empower web developers to create complex UIs
> We very much want the web to win, or at least to stay relevant.
> We believe in open web, and this is why we work on React.
Who is “we” in these sentences, Facebook or the React team? If it’s the React team, then what is Facebook’s motivation? If it’s Facebook, then why on earth would anyone trust it?
The discussion here is motivated by distrust for Facebook, and suspicion about their (your) motives. The specific accusations in the thread above are perhaps a bit out there, but I don’t think it’s addressed well by focusing on the history of React but ignoring the history of Facebook.
React has become, for better or worse, one of the building blocks of the web. Synchronous updates were always a pain, properly encapsulating components was always messy and fragmented, and now there's a standardised way to do asynchronous DOM updates using encapsulated components.
Maybe the Chrome/Firefox DevTools don't, but the standalone React DevTools most definitely depend on WebSockets. My custom React renderer can't connect to them without shimming in a WebSockets implementation, for example.
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.
In self-contained apps couldn't a single prop be passed down that's an object with all things like that in it? Maybe there's a scenario with 3rd-party components where context could make it look more elegant, but I don't have a clear picture.
I know there are several ways to construct a component, but I like that your examples make them functions of props, because that's how I picture a component. Having its behavior depend on a semi-hidden context appears less purely functional. To stretch the term a little, the component is no longer idempotent. Maybe there's a situation where that's what you want, but the examples you've given so far sound like ones where props would serve just fine.
OK, it just boils down to me thinking one explicit prop for every component isn't too much boilerplate. I can see some teams liking the idea of shaving off that explicit prop as long as everybody knows about the implicit context(s) that also affect component behavior.
> 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.
In my experience, examples are only useful if they have two points of comparison side by side.
For example if I'm looking into a new library that claims to simplify my app's architecture or reduce boilerplate, I need to see what the alternative would look like for a given example, otherwise it's just a baseless claim.
Same as things that purportedly "scale". Since every library under the sun claims that as a benefit, I wouldn't even bother recommending any of them to anyone on here without an example of a large app both with and without the library, pointing out the specific sections of code that change for the better.
> 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.
It was a last minute idea and I'm excited about how it turned out.