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

Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

youtube.com

Post reply on HN
Print view View original

41–50 of 66 posts

Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

#41

Post by yazaddaruvala »

danabramov wrote: post #37
yazaddaruvala wrote: post #33

Earlier quoted context omitted.

It would be really interesting to one day have React be a polyfill for an in-browser async DOM renderer. Is that in (very, very, long-term) consideration?

I think my talk paints a relatively convincing picture why DOM nodes aren’t a sufficient primitive if you care about the features I described, as you’d need something like React to orchestrate those updates.

Oh sorry, I didn't do a good job explaining myself.

Currently:

    Application(JS) + React(JS) | Browser(C/C++/Rust)
Possible Future:

    Application(JS) + React(Polyfill - JS) | React(C/C++/Rust) + Browser(C/C++/Rust)
Something akin to the Browser building a "higher level" React-like API/scheduler for the DOM.

Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

#42

Post by sktrdie »

So if I understand it correctly, anything after this line inside the render...

    const movie = movieDeatailsFetch.read(props.id);
    ...
... will block rendering and will defer to a parent component to render instead?

Interesting magic I'd say, since I wouldn't expect such a line to block my rendering.

Wouldn't it be a more "React way" to have HOC component or a render prop that would work exactly like this .read() API?

   
     {movie =>  }
   ...
Then this HOC component doesn't need to have the IO-logic in the render, it can put it in the `componentWillMount` or inside another lifecycle method of React.

What's the advantage of putting the IO operation in the render instead of inside a lifecycle method?

Also, how's race-conditioning done? Does the fetcher library have the logic to only render the last fetcher, or is it more complicated than that?

There's lots of magic, especially in the IO part, and would've loved if he went more into detail on how it's actually done - it's a JS-conf afterall.

Also, a fetch()-promise-based API is not the only type of IO-interface we have. In fact it's only one of many.

HTTP2 for instance is on the horizon offering more complex interfaces with open connections possibly returning several results like websockets - on the other hand a Promise only returns one result and then dies. Observables might be a more interesting abstraction for IO-kind of things.

Also, testing this seems rather complex since the render is effectively doing a side-effect.

In any case, cool lateral thinking and I love hearing these type of talks about cool new futuristic stuff rather than some boring old thing everybody knows about.

Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

#43

Post by spicyj »

anotherfounder wrote: post #21

This is pretty amazing, kudos to the React team! Just hope that SSR isn't an afterthought with this feature. That is probably been my only little grouse with the React team that SSR compatibility is always a 'Not sure, someone should try it' response.

We aren't sure if we'll have time to build it ourselves (vs finding external contributors to build support and upstream it) but this design should handily address the long-standing requests to wait for async data during SSR. We thought about it.

Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

#44

Post by abiodun00 »

pault wrote: post #35
btown wrote: post #3

So glad someone captured this talk! At the 15 minute mark, he introduces a new paradigm for asynchronous IO within render functions; see a screenshot here: https://www.dropbox.com/s/wybqgtftuyqipk8/Screenshot%202018-... . This is groundbreaking, to say the least, as previously this needed to be done by adding higher-order components to inject the result of the fetch as a prop at some higher level; now, it's as simple…

The description of suspending sounds exactly like yielding generators and/or async await; why not build this feature on top of existing language constructs? I am quite sure the react core team has put more than the 30 seconds of thought I have into this question, so I'm curious what their reasoning is for using this implementation.

Seb explains the reason here https://github.com/facebook/react/issues/7942#issuecomment-2...

Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

#45

Post by pault »

abiodun00 wrote: post #44
pault wrote: post #35

Earlier quoted context omitted.

The description of suspending sounds exactly like yielding generators and/or async await; why not build this feature on top of existing language constructs? I am quite sure the react core team has put more than the 30 seconds of thought I have into this question, so I'm curious what their reasoning is for using this implementation.

Seb explains the reason here https://github.com/facebook/react/issues/7942#issuecomment-2...

That's a great thread, thanks for the link!

Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

#46

Post by jefflombardjr »

Klathmon wrote: post #6

I express how excited I am for async rendering. In my experience React has had 2 major paint points. async anything, and styling. And this fixes the former, and I'd argue that the latter isn't necessarily their job to fix. Also, to have done this in a way that keeps a LOT of backwards compatibility is amazing.

What do you think is so painful about styling in React? Genuinely curious. The scoping of stuff? The organization?

Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

#47

Post by Klathmon »

jefflombardjr wrote: post #46
Klathmon wrote: post #6

I express how excited I am for async rendering. In my experience React has had 2 major paint points. async anything, and styling. And this fixes the former, and I'd argue that the latter isn't necessarily their job to fix. Also, to have done this in a way that keeps a LOT of backwards compatibility is amazing.

What do you think is so painful about styling in React? Genuinely curious. The scoping of stuff? The organization?

There are basically 3 options, and they all have really big downsides:

* CSS modules - can use any CSS preprocessors, fast, can be extracted into CSS files, but it's very hard to "theme" and very hard to style/modify 3rd party components.

* Css-in-js - uses Js to render, using preprocessors is much more difficult, can't easily extract into CSS files, somewhat easier to theme and share.

* Inline styles - even slower, harder to preprocess, harder to extract, but very easy to theme and override.

And all 3 don't work well with one another. So if you get a widget made with inline styles, overriding the color is hard with CSS modules...

Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

#48

Post by jefflombardjr »

Klathmon wrote: post #47
jefflombardjr wrote: post #46

Earlier quoted context omitted.

What do you think is so painful about styling in React? Genuinely curious. The scoping of stuff? The organization?

There are basically 3 options, and they all have really big downsides: * CSS modules - can use any CSS preprocessors, fast, can be extracted into CSS files, but it's very hard to "theme" and very hard to style/modify 3rd party components. * Css-in-js - uses Js to render, using preprocessors is much more difficult, can't easily extract into CSS files, somewhat easier to theme and share. * Inline styles - even slower,…

Thanks for your perspective!

Don't know if you've seen this, I've been toying with this approach: https://www.youtube.com/watch?v=bIK2NwoK9xk , and like the fact that you're writing css, even though it's technically css-in-js.

Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

#49

Post by acjohnson55 »

pault wrote: post #34
btown wrote: post #20

Earlier quoted context omitted.

React isn't changing any logic of the types of props; if you actually pass a Promise as a prop, it will be treated 100% as it was in previous React versions. What's happening instead is that imageFetcher.read() either returns a string OR throws a promise; it never returns a Promise. So either gets instantiated with the fetched Foo, or throws so React.createElement(Component, ...) never gets called in the first place.…

Wow, I never would have considered throwing anything other than an Error. On the face of it, this seems like an incredibly powerful technique, but is it an abuse of a language feature?

My guess is that it won't catch on in the long run. But, you never know.

Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense

#50

Post by btown »

pault wrote: post #34
btown wrote: post #20

Earlier quoted context omitted.

React isn't changing any logic of the types of props; if you actually pass a Promise as a prop, it will be treated 100% as it was in previous React versions. What's happening instead is that imageFetcher.read() either returns a string OR throws a promise; it never returns a Promise. So either gets instantiated with the fetched Foo, or throws so React.createElement(Component, ...) never gets called in the first place.…

Wow, I never would have considered throwing anything other than an Error. On the face of it, this seems like an incredibly powerful technique, but is it an abuse of a language feature?

Python “abuses” exceptions in a similar way every time you iterate over a generator: https://softwareengineering.stackexchange.com/questions/1124...

At the end of the day it’s just a control flow mechanism. And theoretically, if you lack data needed to render, it’s an exceptional condition.

Post reply on HN