React Fire: Modernizing React DOM
github.com
github.com
It also brings up significant package compatibility issues, if even a single package I use uses className I can't upgrade React, if a single one uses class I can't upgrade it. I'd rather not deal with a Python 2 -> 3 situation in React.
Unless you meant that there's no reason the code mod they release won't work - I agree with that.
Edit: babel-plugin-react-html-attrs seems like the right solution to people who want to use “class” in their templates.
You might find that not everybody wants to be the face of something. It can be very stressful and people often dehumanize you in their communications as they associate you and the project as the same thing. Think of all the trouble that Lennart Poettering has dealt with as a result of the pushback to systemd.
But yeah, if you want a heads-up on where the team is headed and what they're working on, it's worth following them on Twitter, and Dan in particular.
Announcements about work in progress (which might be interesting to spectators but doesn't affect anyone's day-to-day usage of React) typically comes from people working on those things.
So you might hear from Brian (https://mobile.twitter.com/brian_d_vaughn) on the Profiler work he's been doing, or from Andrew (https://mobile.twitter.com/acdlite) on scheduling.
I happen to have a large following so I understand why it seems like I'm the only one "announcing" things. Twitter also amplifies it so it kinda feels that way. I encourage you to follow all folks who are currently on our team (see links e.g. in https://wpcouple.com/interview-react-team-facebook-wordpress...).
And keep in mind that announcements directly from me that aren't on React blog/twitter are just that -- things that keep me busy. They're not things you need to know as a React user. When there's something ready that you need to know, the information will be on one of the official sources:
* https://mobile.twitter.com/reactjs
Hope this makes sense!
P.S. I'm trying to not mis-represent my role. I do happen to be a "developer advocate" of sort because I enjoy that kind of work in addition to programming. As far as I know my team is supportive of that. Sometimes I make mistakes and they point it out. AFAIK Jordan (who created React) and past contributors also don't mind my active presence. Jordan is currently busy with Reason — you might want to check that out!
Since you're here... I do wonder, how much of the React documentation did you write? The 'style' of the writing seems to match yours, e.g. when discussing Immutable JS.
Plus in hindsight I could have just looked through this: https://github.com/reactjs/reactjs.org/commits?author=gaearo...
Maybe my PR was too drastic, I could've just removed the call to React.Children.only
I would personally agree that it is not.
I'm sure I'm _far_ from the only one who doesn't follow much of anything on twitter. And, I'm fairly confident that twitter posts rarely hit hacker news front page. I do, however, read various engineering blogs. Perhaps a different track can be setup for WIP and experiment posts the by the core team...
As Dan said, the React blog is where they formally announce things related to React releases and important things the community really ought to know about now. If you follow them on Twitter, you can get insights into what they're working on, and if you don't follow them... well, important comments will still bubble up to other sites like Reddit and HN (as this thread proves), and even if you don't see them here, the critical stuff will be posted on the blog or the official @ReactJS Twitter account when the React team is really ready to officially announce that info in its final form.
I see no reason why they (or any other developer of any kind with a personal Twitter account) should be restricted in what they can talk about. So yes, I would completely say that personal Twitter accounts don't have to be "high signal to noise". A Twitter account is what the owner wants it to be.
Twitter is, IMHO, a poor consolation of a communications channel both for the producers and those consumers interested in non-PR reviewed, non-release React information from the developers but not their insights into spinners, TV shows, and whatev.
My general point is that a more official but still on-topic communication channel could be beneficial. I do not believe people should be restricted in what they post on their personal Twitter accounts in this context.
From the very little I know about some of the developers at FB working on React, but I would be very surprised if this was the case. Just because you might feel bothered by Dan Abramov talking on your behalf, doesn't mean those that worked with him do.
Nobody builds a huge thing by themselves better than multiple people can. Being a senior developer is enabling a few other people to do their best work.
Could someone having experience with Rum or other Clojurescript React bindings, but a better understanding of React coming from more JS like languages chime in with their experience?
And react for js, ("react") is those patterns + patterns for js to make everything (sort of) work without as solid a language to steer one away from various cliffs.
Which is one reason why I don't quite understand why there are class based components at all.
At any rate - my current goal is to try some reasonml+react - and I think it'll feel better. And I'm not surprised cs+react feels more sane than js+react.
There's a really good history at https://stackshare.io/posts/the-react-story .
I didn't realize they didn't start with ocaml, but sml.
And Pete Hunt is:
I should've remembered the bit about sml - it's mentioned here after all! :
https://reasonml.github.io/docs/en/what-and-why.html
I do wonder if it'd be easier to port sml syntax to ocaml rather than make reasonml - I guess not. But it might give similar benefits: a pleasant syntax dialect for ocaml, a mature compiler for js and native, and bringing in th js and ocaml library ecosystems. [ed: but not, perhaps, 90% overlap with js syntax.]
As I mentioned - I haven't really played with reasonml/reason-react - I think maybe some of the impressions alluded to in my first comment came in part from this:
https://medium.com/@Imaginary_Cloud/reasonml-react-as-first-...
In particular sentiments like:
"When using ReasonML, we don’t need Redux anymore. ReactReason stateless components already come with the concept of a build in reducer, which is meant to take care of the problems Redux used to address."
Discussed here: https://news.ycombinator.com/item?id=17143494
As well as the introduction here:
https://github.com/reasonml-community/reductive/blob/master/...
"Reductive
A reimplementation of redux in Reason.
Word of Caution
You might not need this library, especially so in a language which provides good enough construction blocks out of the box. ReasonReact already comes with reducers!"
Also somewhat related (re: state) :
https://reasonml.github.io/reason-react/docs/en/state-action...
Classes in js are just syntax sugar, so even if you're writing classes you're still actually writing function prototypes. As such there's little reason not to support them, and they're very welcome when you have a team of developers that are adapting to modern js development almost exclusively from traditional OO languages.
Another big payoff with clojurescript IMHO is the use of async channels and go blocks in lieu of promises to handle asynchronous operations- It's nice to have what is essentially a form of cooperative multithreading right inside your client javascript code, without the need for web workers.
In my view, React team actually -- discovered a paradigm that's really good and workable.
In comparasing Android SDK UI work -- feels like it was 'invented' rather than discovered.
Too much difficult to follow indirections and wrong abstraction.
When I program direct Android, I find myself introducing React concepts. Most of my Presenters and Views now have CMyState class and its one instance.
I have setState_XYZ, and clear_State associated with that state. I cary in that state backend pagination hints, etc (as an example).
And I use RxJava (in Android) to emulate eventing model of Clicks/Mounts/Dismounts (eg when android screen rotates).
All in all, again, it does seem that React developers (not sure who the credit should go to, Peter Hunt, many others ?) -- discovered an a abstraction that was always there, but was not easily crystalized through other frameworks.
And now it is. I would be happy if others would just emulate it and make it working across UI programming platforms. It supersedes in my mind anything else that I had seen in last 25 years, in this space.
Clojure's simplicity tends to package things up nicer than most other languages, especially a readme, but it's not particularly different from what people are already doing.
On a side note, why is Angular CLI so big (71 MB)? Seems like I could write a couple hundred kilobyte python script that does the same thing (or maybe I'm only using like 10% of its features, idk).
The set of dependencies that CRA uses includes:
- A compiler
- A bundler/linker
- An optimizing minifier
- A linter
- A development server with live reloading
- A test runner
All of those are isolated and scoped to that one project, and they are all build-time dependencies only. It's also important to understand that Javascript packages are effectively distributed as source, which affects the number of files on disk. (Granted, many NPM packages do include unnecessary files in the published artifacts, but Javascript itself is a major factor there.)
Meanwhile, XCode is supposedly something like 8GB installed, Visual Studio is multiple gigs, and if you were to look at the actual file size on disk of any C++ compiler toolchain, that would be a minimum of several dozen megs - those are just usually preinstalled on Linux or Mac systems.
So, context is pretty important here. 70MB for a complete JS build toolchain is perfectly fine :)
Though I actually wish React was more of a framework in the sense that it enforeced, or at least encouraged, a certain folder structure and a curation of state management, Ajax libs etc. A bit more standardization would make it more convenient to use in teams.
I’m a long-time Java developer but I’ve just started using React. I, for example, would like to have the file layout be much closer to the standard maven layout. It’s what I’m used to and it works extremely well. But I completely understand why other people don’t do it that way. And since you don’t have to 100% follow some official way I’m free to set things up in a method that’s more convenient for me if I need to.
Unlike other libraries I’ve come across in my career I do like that to react community seems to have settled pretty well. Straight react is there, and read access popular enough that it’s very easy to find what you nee unlike other libraries I’ve come across in my career I do like that to react community seems to have settled pretty well. Straight react is there, and redux is popular enough that it’s very easy to find what you want to know.
When it comes to tools you have a very large number of choices, but the existence of create-react-app makes things easy. Even if you don’t use it to setup your project Babel, Webpack, and Jest are pseudo-official tools that most people seem to use. You don’t have to use them, but you also don’t have to evaluate five choices and try and pick one.
Somethings aren’t quite as clear-cut, like flow versus typescript if you want type checking.
But by and large all seems to work very well, it’s FAR better than I was expecting from the JavaScript ecosystem based on past (and admittedly very old) experience.
The frameworks themselves aren't that difficult to learn. Since Angular 2, they all work in a pretty similar way...
The react team obviously works well together, the vision is here and as an engineer who's been doing frontend work for 15 years (using flex, vanillaJS, various home-made frameworks, backbone, knockout, angular, etc) let me tell you I've never seen another framework/library come half way close to React.
By the way, why not use this big, breaking release to start offering another way to write stateful components from functions? (ES6 classes, prototypes and anything that forces me to use "this" are still part of the very bad parts of JS, imo)
Yes, they've said several times they want to introduce a "stateful functional components" API, but based on comments I've seen, that's probably still about a year or so off.
React is from an era where you could assume a relative static, closed-world, set of built-in DOM elements, with largely attribute and children-based configuration. Now we have open-world set of user-defined elements, and Layered APIs like <virtual-scroller>, that have rich property and method-based APIs. And it seems they will still be difficult to use from React.
> At this stage, the project is very exploratory. We don't know for sure if all of the above things will pan out. .... If there's some area you're particularly interested in, please let me know and we'll work it out.
So, I'd keep an eye on the discussions and bring this up as something that could be worked on as part of the overall effort.
Maybe this is true at Google, but I just don't see much demand for s/Web Components/Custom Elements.
React is a very thin layer on top of JS. `className` is JS. Specifically, it comes directly from DOM APIs. Changing it to `class` (while retaining all other DOM API-compatible prop names) is a really terrible decision that relies on “the wisdom of the crowds”.
And most of the time you see it you’re making JSX elements, where you would expect to use the word ‘class’.
I think they’re right it’s more consistent with what people would expect to happen.
The fact there is a special note in the docs calling out that everyone gets it wrong is a sign it was a problematic choice.
Because in JS that attribute/property is `className`. Because `class` is a reserved name in JS.
Same goes for `htmlFor`, for example. So now you will have a situation where all props directly correspond to DOM APIs, and one prop that isn’t. A strange choice given how the stated goal is to be more consistent with DOM APIs.
https://github.com/facebook/react/issues/13525#issuecomment-...
>"I think this is the primary reason it's desirable for props like tabIndex, cellSpacing, and most other DOM-related props to follow the camelCase convention. It's not because they're DOM property names. It's because they often end up in component APIs. And we want component APIs to be consistently camelCase."
Current state of things:
- React is inconsistent
- API is camelCase
Proposed state of things:
- React is inconsistent
- API is camelCase
- `className` -> `class`
Perceived benefits:
> If React was open sourced today, it seems like the pros of allowing class (closer conceptually to what most people expect, less typing for the most commonly used prop) outweigh the downsides (slightly more typing to intercept it — in which cases you'll probably just want the spread operator anyway).
Actual downsides:
- the entire ecosystem that depends on `className` stops working (huge upgrade effort)
- the entire vast body of books, tutorials, examples, code, posts, articles becomes ever so slightly invalid
- the only valid JS remaining is additional typing: `const {class: cls} = props`. Every other possible use-case in plain JS becomes invalid
- React API remains inconsistent, and breaks further assumptions (why `htmlFor` not `for` etc.)
If I were a product manager, my immediate reaction to the change would be: wat?
This change is at least somewhat warranted, as it makes things more consistent with the DOM.
What are the reasons for `className->class`, `htmlFor->for` besides the "it's longer to type" when the many downsides to the decisions have been spelled out in no uncertain detail in the issue?
It can't be "We're already allowing passing class down to the DOM node in React 16" because you're confusing a bad decision (allowing `class`) with requirements for the change ("we now have to change className to class"). Honestly, the whole className->class lacks any real justification.
So yes, to quote yourself:
> using a React component should feel like idiomatic JavaScript.
Idiomatic Javascript is:
- no reserved words as variable names (`class` and `for` are reserved words)
- className, htmlFor etc. because that's what they are in Javascript
- in your insistence that everything needs to be camelCase you forget that `className` and `htmlFor` are already camelCase
So the main issue you seem to have is this:
> React Is Not Just Setting Properties
^ this is what causes all the problems, and this is what needs to change. Not additional confusion where "idiomatic Javascript" somehow ends up having to use reserved words and workarounds for those reserved words.
Similarly when you add a style to an element you don't get to use `background-color` for instance, it's `backgroundColor`. Yet they're not revisiting that decision, even though it's exactly the same, i.e. `background-color` can't be used to to a JS syntax conflict.
It seems arbitrary to make JSX attributes pertaining to a DOM that don't have a namespace match XML attributes in a markup language... while not at the same time doing the same to the CSS object model property names for instance.
That is more JSS which is one attempt at CSS-in-JSS. The removed hyphen is needed because JSS requires property names as object property names where hyphens can be problematic.
Other CSS-in-JSS libraries, such as emotion.sh, has support for CSS (vs JSS above) inside of JS, including React components, and can keep default CSS syntax. Example from the emotion.sh homepage:
const Link = styled.a`
min-width: 12rem;
margin: 0 auto 20px;
padding: ${props => props.primary ? 18 : 16}px;
border-radius: 5px;
text-decoration: none;
border: ${props =>
props.primary ? 'none' : '3px solid currentColor'};
background: ${props =>
props.primary &&
'linear-gradient(90deg, #D26AC2, #46C9E5)'};
color: ${props =>
props.primary ? '#1D2029' : '#D26AC2'};
&:hover {
opacity: 0.95;
}
@media (min-width: 768px) {
margin: 0 20px 0 0;
&:last-child {
margin: 0;
}
}
`
render(
<div
className={css`
background-color: hotpink;
&:hover {
color: ${color};
}
`}>
This has a hotpink background.
</div>
)
> The backgroundColor vs background-color thing has nothing to do with React.
You’re right, but it absolutely has to do with ReactDOM which is being discussed here.
Which, btw, is called ReactDOM not ReactHTMLandCSSandStuff.
Although reading Dan Abramov’s further comment ReactDOM is a bit of a misnomer, but from an API perspective it’s definitely more DOM especially with the CSS precedent and lack of XML namespaces vs. the `aria` attributes being the only major evidence to the contrary. I mean, sure it only sets `x` properties directly, but as an end user of the library what do I care about the internal implementation?
Edit: A new `classList` property that accepts an array would be nice as that way anyone using `className` has a superior API to migrate to and stay away from this change entirely. It’s not like it’s setting it directly so just convert to a DOMTokenList on the fly.
Although it does seem like ReactDOM already does some weird stuff already in regards to vendor prefixing.
https://github.com/facebook/react/issues/13525#issuecomment-...
tl;dr, There's already a lot of inconsistency, this is not a good argument.
That said, I don't like the className->class change either. It's a reserved keyword, it always made perfect sense why they originally went with className.
grumbles
revises React lecture slides
({ class: className }) => <div class={ className } />
This was one of my reasons for only using Preact. Preact is a lot simpler mental model than react. It’s smaller, faster and arguably has less nuances.
“The Programming Steamroller Waits For No One“
Also:
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
“Fire and Motion”
The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Facebook. People get worried about React and decide to rewrite their whole architecture for React because they think they have to. Facebook is shooting at you, and it’s just cover fire so that they can move forward and you can’t, because this is how the game is played, Bubby. Are you going to support Saga? Flow? React Native? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond?
The implication I'm getting out of it is that you feel the React team is deliberately reinventing things to force the web dev ecosystem to keep up with them (specifically per the sentence "The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features."). From my perspective, that's not the case at all. In the last couple years, they have:
- Rewritten React's internal architecture completely based on lessons learned and long-running design goals, giving them a solid foundation to build new features (and without changing the public API)
- Added new features and capabilities based on that new foundation, including many things the community has asked for (rendering arrays, improved context, etc)
- Implemented most of a new feature set that should allow React users to simplify much of their async data loading logic, on an opt-in basis.
- With that winding down, started tackling cleanup and technical debt issues to make behavior more consistent
Sure, that process has all resulted in changes (such as the warnings about deprecated lifecycle methods), but it's been an incremental process, and they've offered up codemods to help with changes for things like lifecycles. The end goals here are better apps and more consistent behavior, not trying to beat down competition.
edit
Since the parent updated with a modified quote from the article that uses a bunch of React-related references instead, I'll respond to that.
The suggestion here seems to be that Facebook is deliberately trying to waste everyone else's time keeping up. As Dan Abramov recently said (https://twitter.com/dan_abramov/status/1033806477306331136 ):
> There’s a common misconception that React is some sort of strategic investment and receives direction from the top. That’s not the case; pretty much all development and planning comes from the team itself. React is useful to FB but FB org is built around products rather than tech
Also, I'll point out that "sagas" are a Redux ecosystem addon for managing side effects, and neither Redux nor Redux-Saga are owned by Facebook in any way.
https://github.com/facebook/react/issues?q=is%3Aopen+is%3Ais...
That's it.
There's no hidden agenda here. We want to fix bugs in React. This is our strategy for a group of fixes. If something in the strategy is poor we'd love to hear feedback. But it's a bit perplexing to me that it's seen as us trying to force people to do more work, _or_ that there's some kind of perverse incentives for that. If I'm communicating this badly let me know here or in private (https://mobile.twitter.com/dan_abramov — my DMs are open) how I could do it better.
If you follow the linked issues, they are things we've been planning to do for years. They're hard to fix in isolation which is why we thought it would help to bring them under a single umbrella. We're not trying to play some kind of trick on you -- if you used React heavily you're likely familiar with all these problems, and they probably bit you at one point or another. We're always trying to improve React, and we finally got to this set of issues.
Attaching events to the root ( https://github.com/facebook/react/issues/2043) is a four-year old issue. We have tried to do this in the past (https://github.com/facebook/react/pull/8117) but the effort fizzled because it's too hard to fix incrementally. But it's an important problem and we regularly bump into the consequences of it.
Syncing the value attribute has caused a security issue that was widely discussed on HN (https://news.ycombinator.com/item?id=16422696) and caused countless linked bugs. So we want to change it back, but it's a major one so we also put it under the umbrella.
Simplifying the event system is something we hear about almost every day -- both from the bundle size perspective, and from the bug reports I linked which have to do with the complexity of our existing polyfills.
Edit: wanted to add one more thought regarding the rephrasing of Joel's article in the grandgrandparent.
I don't think replacing Microsoft with Facebook makes sense in this context. Microsoft was creating a developer ecosystem on purpose. Because they are an application platform. Facebook is not an application platform for React apps. The reason we get paid to work on React is because it's useful _to_ Facebook — not because Facebook wants _you_ to build with it. If engineers and a few managers above the React team didn't care strongly about open source in the beginning, and that in turn didn't attract more people who care about open source to the team, React would stay within Facebook and keep evolving there. So I can see why you want to apply this analogy, and it might even make sense for the educational industry that appeared around React, but it has little to do with Facebook or React itself.
Therefore it now seems like there _is_ incentive for Facebook to want outside developers to use it.
Thanks.
What I’m trying to say here is not that we don’t value open source contributions. But that much of the driving force behind how React is developed comes from the team itself. Not executives.
Next: Tempted to say, "don't feed the trolls".
Finally: it seems to me that all too often React the library gets conflated with "React" (+Redux, +[middlewares], +Webpack, +Babel, +Node) the ecosystem.
Judging by the first link, GP isn't really trying to accuse React project of trying to block other JS frameworks with suppressive fire. I think the point is, it's yet another encounter with the ever accelerating, already significant-fraction-of-lightspeed fast steam roller of modern/fashionable programming stacks.
In that process there will probably be some breaking changes, but Facebook has some insane number of components they use internally, so they try to never make any breaking changes that can't be automatically migrated.
They seem to have opposite rationales (class is less pedantic and onInput is more pedantic) and I expect at least one of them will get dropped along the way but we'll see.
And while I'm not sure if I'm on board with all of the changes, I'm in no way worried about having to do anything instantly.
But even Java changed A LOT in 5 years...
You always have to keep up as a developer.