Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Fire: Modernizing React DOM

github.com

Post reply on HN
Print view View original

101–110 of 113 posts

Re: React Fire: Modernizing React DOM

#101

Post by danabramov »

ec109685 wrote: post #64
danabramov wrote: post #24

Earlier quoted context omitted.

My motivation for writing this up was going through this list for the last two weeks: 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 wor…

Don’t you also get feedback, pull requests, bug fixes and suggestions from the community that are both beneficial to react but also to Facebook as well? Therefore it now seems like there _is_ incentive for Facebook to want outside developers to use it. Thanks.

Sure, and that’s very helpful. But we also spend months of work on things that affect open source (like gradual migration strategies) that aren’t beneficial to Facebook per se. So from a business perspective it’s not a clear-cut case. Sometimes it can even challenging to justify some kinds of work. But we believe in it.

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.

Re: React Fire: Modernizing React DOM

#102

Post by danabramov »

dmitriid wrote: post #100
danabramov wrote: post #98

Earlier quoted context omitted.

It will be fully consistent if we change `for` too (and a couple of rare SVG attributes).

So, with `for` you will introduce even more JS-incompatibility, break even mire stuff (basically, all forms), and the reason for the change is?.. Somewhat less typing (which is already covered by autocomplete in everything but Windows Notepad)?

onChange is going to affect forms anyway. So it’s not like this code wouldn’t need to be revisited.

Re: React Fire: Modernizing React DOM

#103

Post by [deleted] »

__s wrote: post #97
__s wrote: post #44

Earlier quoted context omitted.

This may be the wrong place, but in response about being a "developer advocate" what about other react projects? react-document-title has a few pull requests without any feedback, I've personally been sidelined since Februrary https://github.com/gaearon/react-document-title/pull/53 when I made a pull request to avoid having to wrap multiple children in a React.Fragment that's child to a DocumentTitle Maybe my PR was…

A reflection: here is someone who's a bit lost on which channels should be used, is looking for feedback, & has in response been struck by the silent disapproval of HN. A sarcastic quip: Thanks for giving some tangible direction on what the correct social behaviors are here

[deleted]

Re: React Fire: Modernizing React DOM

#104

Post by dmitriid »

danabramov wrote: post #102
dmitriid wrote: post #100

Earlier quoted context omitted.

So, with `for` you will introduce even more JS-incompatibility, break even mire stuff (basically, all forms), and the reason for the change is?.. Somewhat less typing (which is already covered by autocomplete in everything but Windows Notepad)?

onChange is going to affect forms anyway. So it’s not like this code wouldn’t need to be revisited.

> Migrate from onChange to onInput... It has been confusing that React uses a different event name for what's known as input event in the DOM.

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.

Re: React Fire: Modernizing React DOM

#106

Post by icc97 »

danabramov wrote: post #61
icc97 wrote: post #40

Earlier quoted context omitted.

Thanks for your reply and your openness. It's great that you find the time to answer random guys on HN. 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.

I wrote some pages in the Main Concepts section. Maybe a few others. Hope it's not bad.

No, the React docs are great, working it mostly as a tutorial works well.

Plus in hindsight I could have just looked through this: https://github.com/reactjs/reactjs.org/commits?author=gaearo...

Re: React Fire: Modernizing React DOM

#107

Post by nojvek »

className -> class. Finally! Also attaching events on the element rather than documenting. Seems like they are actually listening to devs.

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.

Re: React Fire: Modernizing React DOM

#108

Post by Rapzid »

acemarke wrote: post #73
Rapzid wrote: post #68

Earlier quoted context omitted.

It's interesting that the blog needs to be high signal to noise and yet the insinuation there is that twitter does not.. 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…

Dan tweets about React... and music he enjoys. Andrew tweets about Suspense and spinners... and also his thoughts on TV shows, and a bunch of assorted troll tweets. Brian tweets about working on the React DevTools... and also the evening run he's going out on. Seb... okay, so Seb mostly tweets deep thoughts about React and the web platform. As Dan said, the React blog is where they formally announce things related to…

I meant specifically within the context of a platform for the developers to communicate information about React.

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.

Re: React Fire: Modernizing React DOM

#109

Post by chrisweekly »

wLMeOv2qjsFOjZG wrote: post #79
chrisweekly wrote: post #66

Earlier quoted context omitted.

Highly recommend reading Dan's reasoning; it makes a lot of sense. This quote is as close as I can get to distilling it: >"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…

But both class and className are camelCased.

I don't understand the "but" in your uncontroversial comment.

Re: React Fire: Modernizing React DOM

#110

Post by wLMeOv2qjsFOjZG »

chrisweekly wrote: post #109
wLMeOv2qjsFOjZG wrote: post #79

Earlier quoted context omitted.

But both class and className are camelCased.

I don't understand the "but" in your uncontroversial comment.

It seemed to me that the paragraph you quoted does not much illuminate why one should choose for one or the other.
Post reply on HN