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

91–100 of 113 posts

Re: React Fire: Modernizing React DOM

#91

Post by dasmoth »

_uhtu wrote: post #69

I love the react team for what they're doing here, but I have a feeling that the className -> class change would be a huge mistake. It makes it so that the ({ class }) => ... syntax would no longer work since it's a reserved keyword. A simple find and replace is not going to work and a pretty sophisticated code mod would be required, and even then it still means convenient practical uses like the syntax mentioned abo…

Yes, I’m disappointed by this too. It seems to be motivated by thinking about HTML/JSX, rather than the DOM where that attribute really is called className. To me, one of the appealing things about the React model is that the core is a relatively lightweight abstraction on top of the DOM, and other parts of the ecosystem (including JSX templating) are optional. This ends up being one more special case in the React core.

Edit: babel-plugin-react-html-attrs seems like the right solution to people who want to use “class” in their templates.

Re: React Fire: Modernizing React DOM

#92

Post by e12e »

larzang wrote: post #39
e12e wrote: post #36

Earlier quoted context omitted.

I'm just getting my feet wet with react - but my impression from various blog posts and a bit of coding - is that in the beginning there was reasonml (ocaml dialect - mostly (but not only) targeting compilation to js target) - and react sort of "fell out" as a set of patterns/framework from doing functional programming of dom/gui/state. And react for js, ("react") is those patterns + patterns for js to make everythin…

> Which is one reason why I don't quite understand why there are class based components at all. 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…

Hm. I might have to have another look at the implementation of classes in js. I still don't see the benefit of the syntax - but if it really amounts to just convoluted closures over variables, I guess I'll view them with a little less grumpiness :)

Re: React Fire: Modernizing React DOM

#93

Post by e12e »

acemarke wrote: post #38
e12e wrote: post #36

Earlier quoted context omitted.

I'm just getting my feet wet with react - but my impression from various blog posts and a bit of coding - is that in the beginning there was reasonml (ocaml dialect - mostly (but not only) targeting compilation to js target) - and react sort of "fell out" as a set of patterns/framework from doing functional programming of dom/gui/state. And react for js, ("react") is those patterns + patterns for js to make everythin…

ReasonML is a very new language variant, and wasn't part of React's original implementation. There's a really good history at https://stackshare.io/posts/the-react-story .

Thank you (and @scns). I had a hunch it was (an) ml > more programmers > new programmers unfamiliar with syntax > js version and reasonml.

I didn't realize they didn't start with ocaml, but sml.

Re: React Fire: Modernizing React DOM

#94

Post by always_good »

Nihilartikel wrote: post #21

So, I've only used react indirectly via Clojurescript and https://github.com/tonsky/rum for a personal project... I don't spend much time in the front-end otherwise, but every time I read something about using React from JS as one would regularly it feels much, much more complicated. I.e. I just write functions that return hiccup-html lists, and @decorate a cursor into my immutable state structure for reactive update…

For example, you can an approximation of some ClojureScript abstractions with Javascript's MobX: a datastructure that you access as normal and it reconciles render()'s for you.

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.

Re: React Fire: Modernizing React DOM

#95

Post by e12e »

e12e wrote: post #93
acemarke wrote: post #38

Earlier quoted context omitted.

ReasonML is a very new language variant, and wasn't part of React's original implementation. There's a really good history at https://stackshare.io/posts/the-react-story .

Thank you (and @scns). I had a hunch it was (an) ml > more programmers > new programmers unfamiliar with syntax > js version and reasonml. I didn't realize they didn't start with ocaml, but sml.

It's an interesting podcast, but wanders a bit, and there's no transcript. But does mention Jordan Walke who wrote the first prototype of react for Facebook ads. Jordan is currently working on reasonml:

https://github.com/jordwalke

And Pete Hunt is:

https://github.com/petehunt

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...

Re: React Fire: Modernizing React DOM

#96

Post by pests »

quink wrote: post #83
pests wrote: post #78

Earlier quoted context omitted.

The backgroundColor vs background-color thing has nothing to do with React. 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 f…

JSS? ` ` is standard React / ReactDOM. > 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…

Oops I totally forgot about inline styling like that without a preprossor. You are correct.

Although it does seem like ReactDOM already does some weird stuff already in regards to vendor prefixing.

Re: React Fire: Modernizing React DOM

#97

Post by __s »

__s wrote: post #44
danabramov wrote: post #32

Earlier quoted context omitted.

We generally post on our blog when something is _ready_. Blog has to be very high signal/noise ratio so we don't announce something that might be experimental or has a risk of changing significantly there. Because it creates a lot of churn. 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…

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

Re: React Fire: Modernizing React DOM

#98

Post by danabramov »

dmitriid wrote: post #90
danabramov wrote: post #62

Earlier quoted context omitted.

So I wrote in detail why I think `class` is the right choice here. Hope it helps. https://github.com/facebook/react/issues/13525#issuecomment-...

Leaving my comment here as well for increased visibility: 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 t…

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

Re: React Fire: Modernizing React DOM

#99

Post by danabramov »

__s wrote: post #44
danabramov wrote: post #32

Earlier quoted context omitted.

We generally post on our blog when something is _ready_. Blog has to be very high signal/noise ratio so we don't announce something that might be experimental or has a risk of changing significantly there. Because it creates a lot of churn. 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…

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…

I’m happy to hand the project over to somebody who wants to maintain it. I can’t find time for the long trail of old projects right now.

Re: React Fire: Modernizing React DOM

#100

Post by dmitriid »

danabramov wrote: post #98
dmitriid wrote: post #90

Earlier quoted context omitted.

Leaving my comment here as well for increased visibility: 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 t…

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)?
Post reply on HN