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

61–66 of 66 posts

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

#61

Post by just-boris »

danabramov wrote: post #59
sktrdie wrote: post #42

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? {…

>will block rendering and will defer to a parent component to render instead? Yes, but only after the delay period passes. Before that, nothing will happen on the screen (at least not until I add an inline spinner as one of the last steps). Preventing a spinner from appearing and instantly disappearing on fast connections is exactly what this feature enables. >Interesting magic I'd say, since I wouldn't expect such a…

Thank you! I appreciate all your replies, but want clarify this one:

> This is impossible to express with a HOC without reimplementing the whole React in it.

What is the problem here? We return `null` from the beginning, then spinner, if reached timeout and finally, the provided component, if data has arrived.

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

#62

Post by danabramov »

just-boris wrote: post #61
danabramov wrote: post #59

Earlier quoted context omitted.

>will block rendering and will defer to a parent component to render instead? Yes, but only after the delay period passes. Before that, nothing will happen on the screen (at least not until I add an inline spinner as one of the last steps). Preventing a spinner from appearing and instantly disappearing on fast connections is exactly what this feature enables. >Interesting magic I'd say, since I wouldn't expect such a…

Thank you! I appreciate all your replies, but want clarify this one: > This is impossible to express with a HOC without reimplementing the whole React in it. What is the problem here? We return `null` from the beginning, then spinner, if reached timeout and finally, the provided component, if data has arrived.

Please watch my demo. It doesn’t just unmount the children when I start fetching. It keeps the previous screen in place (and fully interactive) while the new screen is loaded. If the new screen is ready fast enough, then it fully replaces the old screen without any intermediate state (empty or loading).

I know it’s a bit hard to believe because none of JS libraries I’m aware of can do this yet. But that’s what it does thanks to cooperative scheduling and a double buffering-like system we implemented. I totally understand that it doesn’t quite “click” from the first explanation because you really need to try it to get it.

But to explain it again: React doesn’t remove the child tree, it suspends the whole update from committing before the tree is ready. So there’s no “holes” or “spinners” if it loads fast enough.

Intuitively my last example with Img component may help. There’s no a way a leaf Img component could delay the whole page from rendering before. With suspense it is possible.

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

#63

Post by sktrdie »

danabramov wrote: post #59
sktrdie wrote: post #42

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? {…

>will block rendering and will defer to a parent component to render instead? Yes, but only after the delay period passes. Before that, nothing will happen on the screen (at least not until I add an inline spinner as one of the last steps). Preventing a spinner from appearing and instantly disappearing on fast connections is exactly what this feature enables. >Interesting magic I'd say, since I wouldn't expect such a…

Thanks for the answer. Since you're also the creator of Redux, how do you see this suspense feature work together with something like Redux?

I imagine that Redux can continue to be used as before, but instead of using middlewares (redux-thunk) for async things, we'd use suspense instead?

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

#65

Post by [deleted] »

danabramov wrote: post #36
btown wrote: post #32

Earlier quoted context omitted.

It seems from https://github.com/facebook/react/blob/master/packages/simpl... that in the live version you'll be specifying which cache to use; this could be global, provided via React's old or new Context APIs, or passed down through props. And you could always write your own fetcher factory if you want to do something really custom; there's nothing special about the SimpleCacheProvider, and it doesn't use any React…

FWIW my demo code looked like export let cache; function initCache() { cache = createCache(initCache); } initCache(); export function createFetcher(fetch) { const res = createResource(fetch); return { read(...args) { return res(cache, ...args); }, }; }

[deleted]

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

#66

Post by aappddeevv »

I think my only concern for throwing a Promise to do a non-local goto and cause the scheduler to delay rendering that component is whether the thrown Promise can be caught by mis-behaving code that makes it difficult to debug what's going on. It would be nice to have a more line-of-sight API as well vs only an exception based model.
Post reply on HN