React-basic: Description of the conceptual model of React | Hacker News Reader

React-basic: Description of the conceptual model of React

github.com

268 pointsswyx70 comments

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

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

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.

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?

Immediate mode is really the sweet spot for games, I still do most of my experimental UIs using immediate mode on top of canvas for that reason. If you need to write something like a code editor, it is just much easier than fighting the DOM (you can easily do your own caching using images), though you have to roll a lot on your own.

The problem with gaming is that you usually don’t want to use the DOM, and React’s value add is mostly in its DOM handling.

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) I know there are similar parallel approaches like https://github.com/FormidableLabs/react-game-kit and 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...

So I've never done game dev - can anyone explain what immediate mode rendering is like to a React webdev?

In the simplest way possible, it would be like running

   this.element.innerHTML = "new value"

instead of

   this.setState({text: "new value"})

React's method of async state setting is really great when you have a bunch of components that know little to nothing about each other, because it'll automatically batch things up. But in some situations, and games are a perfect example, you need the value to change right now.

Actually, that looks like retained mode.

Immediate mode simply means you specify what to redraw on every frame, there is no caching unless you specify it. And you basically redraw whenever some state changes (in a game this is going to be at frame rate).

In React, when some state changes, you respecify the DOM for components whose state has changed, but asynchronously the library determines how to make the DOM update more efficient on the next frame redraw.

thanks, what is the benefit of no caching then? seems fairly wasteful if you have an engine capable of rendering at frame rate already.

Simplicity. Retained-mode means you modify the scene graph (aka DOM) using imperative statements, it is difficult to keep your UI in synch with your models. With immediate-mode, you simply create a function f(m) over your model m to render it on each frame rate (which also often involves imperative instructions affecting the frame buffer, but the buffer can be cleared on each frame so who cares).

Retained-mode caches by default (often in opaque ways), which was the whole point (only re-render parts of the scene that have changed). You can roll your own caching for immediate mode, usually via some kind of invalidation scheme (use image for a node if nothing changed for this component, otherwise call that node's re-render method). On the other side, projects like React takes the retained-mode DOM and make it look more like an immediate-mode abstraction without sacrificing so much performance.

thank you!

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

https://github.com/reactjs/react-basic/pull/7

Thank you, that was really helpful.

It's much clearer now :+1:

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

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

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

dead and gone my friend. deprecated.

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

Can you elaborate?

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

  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.

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.

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.

No. People want to have their components styled without the fear of breaking them with an external style. Hence CSS-in-JS etc.

There are two ways to look at your code: https://i2.wp.com/pbs.twimg.com/media/DCXJ_tjXoAAoBbu.jpg?w=...

React mostly makes you think in terms of components.

Also: React doesn't output HTML.

Sure CSS in JS if you want. But scrapping CSS for style tags is a bad idea.

React renders to the DOM which outputs HTML. It's still HTML that can be styled with CSS independently of React.

> Sure CSS in JS if you want.

What do you think the code you complained about does?

> But scrapping CSS for style tags is a bad idea.

It's not bad in this particular case because these were simple examples to illustrate an entirely different point.

> React renders to the DOM which outputs HTML. It's still HTML

Erm. No. DOM never outputs any HTML. There's no HTML generated when you use React (or any other DOM-manipulation library or vanilla Javascript).

It's the other way around:

- HTML gets parsed

- A DOM (Document Object Model) is created to provide an in-memory, well, object model of the HTML document.

- In order to render anything on screen the browser works with the DOM only

- When something manipulates the DOM directly, the browser reacts to those changes and re-renders the view accordingly

- There's no HTML generated

- If someone does change the HTML, it's re-parsed, go to step 1.

Yes, you can style DOM nodes independently of React because that's how CSS works. However, there is a reason why people hate CSS with a passion: it doesn't scale, it's cumbersome to develop components with it etc. etc. etc. And that's why people ended up inventing ways to include/generate CSS via JS alongside component code.

Fair enough on the DOM rendering, you're quite right. Instead of "React still just outputs HTML" in my original reply I should have said "React still just renders to the DOM".

> these were simple examples to illustrate an entirely different point.

I did accept this in my original post, it could be just because they were examples. But it's trivial to use classes instead.

I've never come across many people that hate CSS with a passion. It's been used to create billions of pages so I'm sure that some people will hate it but it was certainly a step up from individual style tags.

The React docs agree that it's more efficient to use CSS instead of inline styles [0]. And beyond that when talking about CSS-in-JS:

> if in doubt, a good starting point is to define your styles in a separate *.css file as usual and refer to them using className.

There are problems with CSS, but it also solved a lot of problems that came before that seem to have been forgotten about.

[0]: https://reactjs.org/docs/faq-styling.html

I don't think anyone hear hates CSS - it is a convenience in many ways. However when you think of views as a reflection of state, it can become very confusing and "impure".

Imagine you had a complex database of authors and books, and every time you read from it you want to receive the name of the user or the book in title case. You see that this behavior can be abstracted over, so you say "any time I pull a record from the database, no matter what table it comes from, capitalize its title". This is very convenient.

Well, no one would ever do this in a complex application, because you don't know what sort of implications it might have for future tables that are added - or what if you decide that short words in the title should be lowercase? Now you are making exceptions instead of declarations.

This is effectively what CSS does. it unnecessarily couple's visual state to other visual state, unless it is namespaced uniquely to a specific component.

I didn't think so either but this is what I was replying to:

> However, there is a reason why people hate CSS with a passion

So it seems some people do. Going through some of the talks about CSS in JS it seems Facebook and Airbnb are making good cases for the problems they're hitting with CSS especially around asynchronous loading of CSS files.

But having spent lots of time seeing what a mess developers come up with using style tags on individual elements before switching to using CSS I'm interested to see what happens when there's tons of React components with hard coded styles. It seems like a solution that's ripe for creating more problems than it solves.

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.

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)

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

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"

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

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

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?

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.

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

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.

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.

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.

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.

Why do you disagree with it?

Lets say, it's not in alignment with the particular set of values I hold as a developer.

Could you elaborate? Or if not, I'm extremely curious why you seem to be dodging a question like this...

EDIT: maybe it's 'just picking a fight' for the sake of it? https://news.ycombinator.com/item?id=16430826

Nothing sneaky; Nobody wants to read the giant wall of text I have to say. So... i tried to give a summary of it.

I feel one way, others feel a different way... who's right? who's wrong? all a matter of what matters to you. For what matters to me, react is totally wrong. I am still trying to "see the light" but I have yet to.

But then what's the point of taking the effort of writing it down and sending it out into the world? Honest question.

To solicit insight that might help them better understand the perspective? That's why I would make a similar post, anyway.

How can anyone give any insight about their opinion if they don't state it?

It just looks like cargo culting and/or flame baiting.

Hmm. I guess I didn't read it with the same sort of antagonism that others might. It just sounds like he's saying he doesn't get it and that he doesn't see a way to React from his current way of thinking (e.g. Rails). I don't have much experience with these technologies, so I don't have anything useful to contribute that might bridge the divide he's experiencing.

Saying "I look at react, and I see... shit." is a bit antagonistic, no? And then not bothering to explain especially so.

I hold a particular perspective and have expressed it - that's all there is to it.

Reject your sense of injury, and the injury itself disappears.

My sense of injury (or lack thereof) doesn't really have anything to do with my opinion of meesterdude's pointlessly contrarian and somewhat bizarre behavior.

(FWIW, I find React, or the entire 'front-end' ecosystem to still be too complicated and unstable, and usually not worth the benefits SPA's offer. So after about a decade of front-end work I've become quite conservative and have focused my efforts on becoming better at back-end stuff.)

But see, I don't care about your opinion. You asked me to clarify whether or not I find meesterdude's post antagonistic. I don't read posts on the internet in my head with an antagonistic voice. Meesterdude states repeatedly that it's his opinion and also that he recognizes others don't share it. I don't find it antagonistic, because I don't find it antagonistic.

Okay, fair enough :).

Anyways, I have always had immense difficulty accepting someone sharing an opinion without them explaining why, and it's often led me down paths that in hindsight didn't seem very productive or for that matter justified.

So I think I agree with what you've been saying so far and I'll take this whole thing as a personal lesson to learn to deal with that 'quirk' of mine. Because it probably does upset my calm more than I'm aware of and than it's worth. Thanks for the reminder.

I still struggle mightily with it myself. If you're interested in pursuing it formally, a lot of what the old stoics said ended up in writing. Some of the most valuable ideas ever codified and they're freely available online or, if you prefer hardcopy, available literally for the price of shipping from various Amazon sellers. Good luck.

That's great advice. I was really into the stoics a few years ago, but should explore them again. I have found, though, that zen/mindfulness has been more effective for me to actually put all this stuff into practice. I think the combination might be worth a try.

> Nobody wants to read the giant wall of text I have to say.

I do. Because I just might learn something!

But I'll be frank: after your posts in this thread, and the thread linked here, I don't think that wall of text exists, I have some significant skepticism with regards to your ability to generate a meaningful one, and I think you are appealing to it as a rhetorical trick.

Frank, looks like you got me. I'm really just a react dev trying to troll other react devs. Because really, who could have anything against react? How could anyone think its anything but awesome?

OK. Where's that wall of text? Generally one actually substantiates an argument when arguing in good faith instead of just bullshitting. So what's that actual reason that it is, and again I quote you, "shit"?

I think react is very flexible. I wonder if people sometimes mixes react with react "best practices" and get confused? React is close to functional and works very well with those ideas. It also allows you to create components from classes with internal state and use that idea. You can have all state internally or connect some external state library if you prefer that, etc. Jsx is something some people seems to find strange but you don't have to use that either. Almost all react projects do but you don't have to. It used to work with ES5 and ES6 (ES2015) but now the latter is used so much in the industry that it's the only thing they support. You still don't have to put components in separate modules if you don't want to.

So, for anyone reading this and still being confused by react, please step back and think about what you need to know and understand right now which may be much less than everything there is to know about react and if you find some part that you don't like you may be able to avoid it.

That's an interesting point that I think might hew close to the truth.

I'm amazed at the amount of complexity that people seem try and heap on top of React. It's like they have seen the core simplicity and are desperate to complexity it to make it feel like they are dealing with something weighty and significant.

Simple things can be brilliant, React is a simple thing. A simple idea with a simple to use implementation. It's clever. It's good. There is no need to make it complex.

No one ever thought SOAP was cool.

I can definitely remember SOAP being the next big thing that was going to solve all our problems, around 2002.

I suppose SOAP was wrapped up in the whole Service Oriented Architecture thingy that was going on then. The faculty at my university were... sceptical of the approach so I suppose I was in an environment that wasn't going to be pro SOAP when it came along.

SOAP ensures that the service definition, the client implementation and the server implementation are fully synchronized. And types are fully transmitted. (except for collections and null, sic!)

How can you do that otherwise?

PS: i agree that WADL or Swagger can do something similar, more elegantly than SOAP. But can we agree that there is a real need to enforce the coherence between the client and the server ?

To be honest, React is so simple I don't understand what there is to be repulsed by.

Facebook

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

I assume you haven't done much front-end engineering then. Because for all of the many legitimate gripes with React, developer happiness and productivity is one of its strengths. Going from something like manual Backbone views to React components was a breath of fresh air when React was released (there are now other frameworks that'll do the same, but still).

Rails is not a front-end framework, so basically you're saying "I am thankful I am a backend developer, not a frontend one".

Reply on news.ycombinator.com