
React-basic: Description of the conceptual model of React - swyx
https://github.com/reactjs/react-basic
======
firasd
I think by now many HNers will have grasped the idea behind "The core premise
for React is that UIs are simply a projection of data into a different form of
data", but here's a related good read from around the time this was written:
Pure UI [https://rauchg.com/2015/pure-ui](https://rauchg.com/2015/pure-ui)

Also of interest, the classic 'Rethinking best practices' presentation:
[https://www.youtube.com/watch?v=x7cQ3mrcKaY](https://www.youtube.com/watch?v=x7cQ3mrcKaY)

~~~
seanmcdirmid
The problem with retained mode UIs is that they lose the ability to
continuously translate data with functions. Immediate mode UIs don’t have that
problem (since you are just drawing to the screen on each frame), but suffer
from efficiency problems (not to mention you have to do your own layout).
Databinding (e.g. as in WPF) allowed some of these transformation to occur
declaratively, but were too inexpressive in general.

React is a nice new point in the space, and is much more pragmatic than FRP or
Rx.

~~~
davedx
Yes, React is an interesting middle ground that hits a sweet spot for many
classes of web apps. Try and make (real time) games with it and you soon
realize that despite it being a good conceptual model, you really need to be
in an immediate mode rendering mode.

Does anyone know of any immediate mode game engines using concepts from React?

~~~
nervestaple
I'd be curious to know too -- I've been working on a custom React renderer for
the Phaser webgame engine after dealing with a lot of frustration around state
management in Phaser. ([https://github.com/nervestaple/react-phaser-
kit](https://github.com/nervestaple/react-phaser-kit)) I know there are
similar parallel approaches like [https://github.com/FormidableLabs/react-
game-kit](https://github.com/FormidableLabs/react-game-kit) and
[https://github.com/michalochman/react-pixi-
fiber](https://github.com/michalochman/react-pixi-fiber). You can sort of use
them in immediate mode by calling setState inside the update loop, but the
abstraction leaves a bit to be desired...

------
danabramov
The first time I read this I was pretty confused so here’s some annotations.

[https://github.com/reactjs/react-
basic/pull/7](https://github.com/reactjs/react-basic/pull/7)

~~~
porker
Thank you, that was really helpful.

------
swyx
oh wow i thought this was interesting but surprised this is front-page of HN
interesting.

So this is written by Sebastian who is part of the React core team. A lot of
the earlier stuff might seem obvious to most but I think it gets increasingly
non obvious as you go down the list. I would direct your attention to the bit
at the bottom on Algebraic Effects ([https://github.com/reactjs/react-
basic#algebraic-effects](https://github.com/reactjs/react-basic#algebraic-
effects)) - that came up on twitter today in relation to what the mental model
behind React Suspense is (even though technically JS doesnt have Algebraic
Effects itself, thats kind of what they are trying to do with async
rendering.) I'll let gaearon and co explain better if they see this, I don't
want to butcher it.

------
sandGorgon
Dan Abramov of the CRA and React team posted a "diagram of modern React
lifecycle methods. " here -
[https://twitter.com/dan_abramov/status/981712092611989509](https://twitter.com/dan_abramov/status/981712092611989509)

~~~
dorfsmay
As a (very) beginner in the world of React, where is the componentWillMount()
in that diagram / cycle?

~~~
swyx
dead and gone my friend. deprecated.

------
kylestlb
It's funny that memoization is some conceptual model for react but that's what
compilers have been doing for ever and ever.

~~~
icc97
Memoization is a good thing, but not many people understand compliers. So we
should celebrate that React is helping to push it into the consciousness of
front end developers.

React isn't really inventing anything fundamentally new in terms of computer
science but I think they are introducing a lot of people to good concepts that
already existed.

Douglas Crockford was writing about it for JS [0] back in 2008 which is still
a long way behind compilers and, say, Haskell but it has been used in
JavaScript at least a decade.

[0]: [https://stackoverflow.com/questions/3798858/explanation-
on-j...](https://stackoverflow.com/questions/3798858/explanation-on-
javascript-the-good-parts-example-section-4-15)

------
icc97

      function FancyUserBox(user) { 
        return { 
          borderStyle: '1px solid blue'
          ... 
    

Perhaps it's just me being pedantic and these are just examples. But when I
see React examples that set style properties directly it makes me cringe, like
it's ok to go back to a time before CSS just because everything's in JSX.

~~~
WorkLifeBalance
CSS doesn't work, it's a failed model.

It's based off the premise that content and styling are independent. It works
very well when that is true. Often they are not.

If I'm designing a "date-picker" component, it will be completely broken
without the corresponding styling. There can be no separation of content and
style, the content does not make sense without the styling to produce the
actual final output.

Such components require style definitions to function.

~~~
icc97
That doesn't make much sense to me. React still just outputs HTML so there's
no difference in terms of styling.

You're the first person I've heard wanting to scrap CSS and go back to style
tags. Sure people prefer LESS/SASS but having styling in a different file and
not mixed into JSX code makes style changes simpler for the way I work.

~~~
jbergens
React doesn't force you to use any style method, you can output html and use
css as usual.

The problem is that css scales poorly for large projects, especially when you
build many components and mix them together. It is almost impossible to know
which css rules are in effect for a specific part when you don't know where
that part will end up and it is also hard to create css rules that continue to
work since more parts and html may be added later which changes the css rule
matching.

~~~
huehehue
To be fair there are other ways of solving that problem.

If you're worried about class overlap, you can define unique/hash-based
classnames on build with css-loader.

If you're still worried about aggressive stylesheets destroying your
components, you can wrap them in however many classes you see fit (some people
might use `.n.e.a.t.l.i.b .cool-class` instead of polluting component code
with CSS).

As far as CSS scaling poorly, that's really up to you. I find that it's an
afterthought to most people, and full of weird hacks and `!important`s a few
months into a project. That's fine if that's how you want to do it, but it's
not an inevitability.

(I say this as someone working on a component library that's used on over half
a million sites)

------
kace91
>Most UIs are some form of lists that then produce multiple different values
for each item in the list. This creates a natural hierarchy.

I find this idea a little controversial - it is certainly true for websites,
but I don't think it's necessarily the case for single page applications that
have a purpose beyond showing data.

I think in those cases the 'natural hierarchy' approach tends to break and the
idea of passing arguments in a hierarchical manner can become cumbersome. At
least that is my experience so far,

~~~
swyx
Prop drilling was a React pain point for sure but they have solved it with the
concept of "context", which was formally released with 16.3. You can also
regard this as "implicit props", or "implicitly passing arguments by nature of
the hierarchy"

------
Benjamin_Dobell
There's already a gazillion React templates out there, all of varying quality.
Nonetheless, in case anyone is interested, here's a modern (Babel 7, Webpack
4) React SSR template we developed for internal use, but have subsequently
open sourced:

[https://github.com/glassechidna/practical-react-
ssr](https://github.com/glassechidna/practical-react-ssr)

I don't think there's anything particularly revolutionary in there, it's just
a reasonable starting point to hit the ground running.

~~~
Benjamin_Dobell
Out of curiosity, would people mind elaborating on the reason for the down
votes?

If you've looked at the template and there was something you thought to be
sub-standard, then I'd love to know what people would do differently.

If the down votes were because I made _another_ React template, then, ah,
that's somewhat understandable. Although, as I've stated, it was created for
our own internal use, and was simply open sourced because we love open source
and giving back to the community. Additionally, at the time of creation there
absolutely weren't any full-scale open source projects (templates or
otherwise) available using Babel 7 and Webpack 4. Actually, Babel 7 is _still_
not officially released yet, so there really aren't many even now.

If the down-votes were because you think the comment is unrelated to the
source article, well... I don't know precisely how to respond to that
critique. However, the article (and this discussion) is regarding the
underlying principles of React and the linked project is a practical
implementation of React (and the underlying principles). I've specifically
added a new root level comment rather than piggy-backing off other unrelated
comments, which is unfortunately commonly seen on HN.

Is the sharing of related (non-competing) open source projects seen as poor
etiquette?

~~~
blowski
I didn't downvote, but... your comment does feel a bit spammy. If you had
something to say about why you feel some part of the original post is unclear,
and how your link helps to make it clearer, then it would feel more
constructive.

As it is, it just feels like "This post is about React, so here's my project
that is also about React." So I can see why it's getting downvoted.

~~~
Benjamin_Dobell
> If you had something to say about why you feel some part of the original
> post is unclear, and how your link helps to make it clearer, then it would
> feel more constructive.

I guess that's fair, however my intention is still very much to be
constructive. Instead of critiquing the article, I'm _attempting_ to provide
value to the target audience of this article (likely those new to React), in
the form of a code-base to get those interested up and running with React.

> As it is, it just feels like "This post is about React, so here's my project
> that is also about React." So I can see why it's getting downvoted.

I feel as though saying "Hey, seems as you like X, you may well be interested
in some related Y" is actually pretty normal human conversation.

I would have thought that it's only spammy if there's some hidden agenda.
There's no "premium version" or any such nonsense, the only thing I gain by
sharing this is the satisfaction of knowing others may benefit from something
I built - which honestly is pretty great! However, I don't think a supportive
and constructive community should take offense to that.

Additionally, it's pretty normal to see links to related projects on HN. I
guess the down-fall here is that templates, whilst incredibly useful to some,
are _dead boring_ to those who do not require them. If the linked project were
more _interesting_ I'm sure the response would be more favourable.

------
meesterdude
This was insightful to read, I have often wondered what the underlying
thinking was with React. I also disagree with it, but... important to know the
thinking for sure. Also helps explain why it's been such a struggle and has
been less than obvious to me.

I look at react, and I see... shit. As an aside, I'm taking a deep dive
reading u on the nuances of JS, so I'm reading along here and I get whats
going on at a technical level with the JS; but the actual react code... does
not jive with me.

Remember when we though SOAP was cool? React kinda feels like that to me. I
don't think it really represents a way forward in programming.

But you know - I respect that there might be people who totally jive with
react, who's brains work differently from mine and see nothing but awesome.

This also makes me so, so thankful that I am a Rails developer. React is
surely good for certain things, but developer happiness and productivity i
think are not among them.

~~~
eropple
Why do you "disagree with" the idea of functional projection of application
state into views? Because that's all React...is.

And, as a Ruby developer going to React, I _overwhelmingly_ disagree with
regards to both developer happiness and productivity; I write better, more
testable code, faster, when building out a React frontend than I have in any
other system I've ever used, bar none.

~~~
meesterdude
why did you put 'disagree with' in quotes? I don't think its an idea that
accurately encapsulates what a UI is. I'm not saying thats not what drives
reacts philosophy... I just think there's more to it. If we're talking about
first principles, I think that would a little blunt of a perspective.

~~~
Vinnl
I think the quotes were because they... Quoted you.

Anyway, your comments don't really add anything unless you share what you
think is an accurate representation of UI - otherwise, there's nothing we can
learn from it, other than that you disagree with the design of React.

