and associated HN discussion here: https://news.ycombinator.com/item?id=16492973
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
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.
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.
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.
