
Sneak Peek: Beyond React 16 [video] - montogeek
https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html
======
aeontech
Video of Dan Abramov's demo here:
[https://www.youtube.com/watch?v=v6iR3Zk4oDY](https://www.youtube.com/watch?v=v6iR3Zk4oDY)

and associated HN discussion here:
[https://news.ycombinator.com/item?id=16492973](https://news.ycombinator.com/item?id=16492973)

~~~
urs2102
Firstly, this is super cool. Writing loading this easily based on different
connections is going to be awesome. The suspense stuff is great.

Secondly, Dan has to be one of the nicest people on the internet. If you don't
follow him on Twitter, give him a follow. He is so helpful, and understanding
of his users' problems. I think it's a huge reason why the React team is
constantly pushing boundaries. They really do listen.

It's not just Dan though, the community really has some great people. Dan had
actually tweeted a bunch of people worth following a couple months back, which
I compiled into a list:
[https://twitter.com/udayrsingh/lists/react](https://twitter.com/udayrsingh/lists/react)

------
egeozcan
As far as I understand:

If you throw a promise (throw as in throwing an error) from the render
function, React will retry when it resolves. `createFetcher` is a cache layer
so that you don't DOS your own server on re-renders. Maybe though encouraging
people use a ServiceWorker for that would have made more sense (edit: it also
throws the promise for you when you access the cached value. so, yeah, it is
very well-thought indeed).

Apart from that, this seems to be very simple to use, well-thought and useful.

~~~
danabramov
This sounds about right. I would note the atomicity of the actual screen
update. We don't flush the changes until the whole tree resolves. Another
thing to note is that we try to render as much of the tree as we can (e.g. if
a sibling asks for a retry, we still try to render other siblings so we can
collect as many requests as possible).

------
daveroberts
This is very cool. I'm heavily invested in Vue.js, but seeing these kinds of
features of the horizon with React makes me a bit jealous.

The APIs do see unintuitive, but as Dan said, they are not finalized yet. I
remember trying to implement a drag and drop component in React and having a
bit of trouble with complicated APIs. Hopefully this keeps getting cleaner.

------
vga805
I'm eager to play with this and to try out some ideas.

For example, I wonder if it's possible to pass createFetcher an async function
that awaits a fetch, dispatches a redux action with the data as a payload,
then returns the data. If create fetcher works this way, it would seem to
obviate a bunch of the usual redux actions. instead of FETCH_DATA,
FETCH_DATA_SUCCESS, and FETCH_DATA_FAILURE, you could just have something like
SET_DATA.

