Maybe a dumb question or wrong forum. But how do you start using latest React in a project?
Npm has alpha versions react@16.4.0-alpha.0911da3 and react-dom@16.4.0-alpha.0911da3 you can experiment with.
there be bugs
Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
31–40 of 66 posts
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#32So 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…
Is the cache global?
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 internals.
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#33Is there plan to implement the react-core in C or other native language ? I can see that being compiled to webassembly for browsers and react-native can have multiple language support ?
No, there's no plans to rewrite the React core in C, Rust, Reason, WASM, or anything else right now. Lin Clark, who works for Mozilla, gave a talk on "What WebAssembly Means for React" last year ( https://www.youtube.com/watch?v=3GHJ4cbxsVQ ). In a recent Twitter thread, she said that some more useful WASM pieces are in the works, but still not likely to be a big improvement or worth the effort to rewrite React ( htt…
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?
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#34Earlier quoted context omitted.
So I am guessing if a prop is `instanceof Promise` or some other constructor then it must trigger this response . . . is that correct?
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?
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#35So 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.
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#36Earlier quoted context omitted.
Is the cache global?
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);
},
};
}Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#37Earlier quoted context omitted.
No, there's no plans to rewrite the React core in C, Rust, Reason, WASM, or anything else right now. Lin Clark, who works for Mozilla, gave a talk on "What WebAssembly Means for React" last year ( https://www.youtube.com/watch?v=3GHJ4cbxsVQ ). In a recent Twitter thread, she said that some more useful WASM pieces are in the works, but still not likely to be a big improvement or worth the effort to rewrite React ( htt…
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.
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#38Earlier 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?
Is a feature of the exceptions to let you handle exceptional cases far away from the caller, up in the stack.
You should keep a distinction between exceptions that means "error" and exceptions that means "some kind of event happened", and handle them accordingly.
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#39This 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.
Also curious how this would work with SSR? Will the render be considered incomplete until all subtree promises have resolved?
If so, that would solve one of the biggest pain points working with SSR + React today. Today, the solution is to have you route level component load data which is far from ideal.
Re: Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
#40Earlier 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.
Hello Dan,
Great talk ! My thinking behind the top statement was with a native implementation of react-core, the react-native story becomes more compelling with JSX(ish) UI templates / CSS Styles and multi language business logic support.
Once you have this, the browser becomes another target. I see Flexbox implementation is already native with Yoga [0].