Sneak Peek: Beyond React 16 [video](reactjs.org)
reactjs.org
Sneak Peek: Beyond React 16 [video]
https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html
7 comments
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
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
Note that the video embedded in the post is higher quality. :) Useful discussion link, thanks.
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.
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.
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).
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.
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.
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.
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.
and associated HN discussion here: https://news.ycombinator.com/item?id=16492973