The decorator-based approach sounds interesting, but (in my understanding) it will require moving the data fetching logic away from the main component into the decorator, which also creates a level of indirection that is intransparent to the component user, and I imagine stacking several of these decorators on top of each other should provide plenty of room for unforeseen side effects as well.
Personally, I think almost all components should be "dumb": They should just receive the stuff that they display as properties from their parent components and report changes back through callbacks. They should not perform any "controller logic" beyond form validation and input serialization. Only a few components at the top should be responsible for fetching and distributing resources from the backend. Typically, it should suffice to have an "Application" component that takes care of fetching stuff that every other component should see (e.g. data about the user), while components one level below the application should fetch stuff that is specific to the given page/view that is being displayed.
Unfortunately, compared to the humble beginnings a few years ago I feel that the whole React.js stack gets more and more bloated these days. As an example, managing state through Redux requires writing actions, reducers and implementing a subscriber pattern in my components, just to fetch some data from the server. I mean, if we're writing a version of "Photoshop" for the browser this level of complexity might be warranted, but in most cases we just want to fetch some JSON, display it nicely formatted to the user, let him/her click on it and possibly send some data back. If we need 500 kB of Javascript libraries to do that while having to patch/reinvent many other things that we took for granted before -like simple hyperlinks (I'm looking at you, react-router)-, chances are we're doing it wrong.