/actions: Flux action creators
/components: These are all the JSX React components (the presentation layer) - so there are subfolders like "pages", "controls", etc.
/reducers: These are Redux reducers - they're the logic that handles all of the application state
/services: This is what your question was really about. We use basic ES6 modules for services, with methods like "fetchUser(id)" which use the new JS Fetch API behind the scenes. We then have redux-thunk and redux-promise middleware so we can easily offload state manipulation to these services without actually putting state logic in them.
I've set up a few React projects at this point and this always seems to keep a nice separation of logic. I'm never asking where data is coming from or where it's going. I think Redux has been the biggest difference maker when dealing with all of these parts.
It's no framework, but it's composed of well understood libraries, each with their own important function. You build the structure out yourself so you know exactly how it works, and the pattern will be very familiar to anyone who has used React before.
Personally I don't see a huge problem with either resolving or rejecting with a message about the cause of the result. Others see it differently but they haven't been able to make any progress on a major problem.
If you want to avoid this altogether there's no reason why you can't use a different library.
Rxjs provides the observable data type. The extensions are functional reactive operators. There are operators used to retry, throttle, filter, debounce, etc.
Angular2's http module is already based on Rxjs observables for this exact reason.
* redux: Keeps track of all the state (UI and domain) in a single object.
* immutable.js: Obviously for the immutable data structures which plays nicely within the React ecosystem. It also has a rich set of data structures that aren't found natively within JavaScript. For example I make heavy use of Records to simulate domain models.
* react-router: For routing within the application.
* superagent: For ajax calls.
* reselect: If using redux you'll cherry pick various parts of the state tree for your components. If any of the data used within components can be derived then reselect comes into play nicely.
It took longer than I had hoped but I finally have a strong set of libraries and project layout I'm happy and productive with.
And how do you ensure your detail components (WidgetDetail, or WidgetForm) have the widget loaded before displaying? asyncConnect?
Thanks in advance for any pointers!
I prefer a domain folder structure versus splitting things by function. So instead of folders like "actions/userActions.js" and "reducers/userReducer.js" I'll do "users/actions.js" and "users/reducers.js".
Ping me on github if you have any more questions.
If you start using a flux implementation like Redux, there are other interesting things you can do to handle api requests [3].
[1] https://github.com/visionmedia/superagent
[2] https://github.com/facebook/react/wiki/Complementary-Tools#d...
Having simple and easy to create components is a major win. No one on my team ever liked or used directives much, as they were overly complicated.
Redux has been a huge win. In dev builds, every state change is output via a redux middleware, so it is easy to watch how state updates and transitions. In prod we plan on storing state updates and allowing them to be sent to support for trouble shooting. Even have plans for an overlay to allow support to step through those changes with a simple interface.
[1]: https://github.com/matthew-andrews/isomorphic-fetch
[2]: https://github.com/pburtchaell/redux-promise-middleware/blob...
Angular 2 is much more OO style GUI lib - if you've ever worked with stuff with WPF you'll recognize the patterns immediately - focus on DI, property bindings and attributes, class based design, etc. It really works well with TS and IDEs
React + TS is quirky to say the least - not just the base lib but the ecosystem - for example immutable.js is annoying to use with TS (creating typed records). It can be done but I'm not sure it's worth the effort.
But one huge consideration is that React has been "out there" for a while now - there's a ton of quality work available on top of it. In Angular 2 even the basics are in flux like animations and stuff like material design components are nowhere near in sight.
I'm using redux for API calls - I like the "single store" approach despite drawbacks vs. flux (or multiple stores).
I think this aspect makes Angular feel more like the "Java EE" of the web world. You can throw an Angular developer at an existing Angular code base and I'm fairly certain he'll know exactly what goes where and how things are strung together without much digging around or documentation required. For enterprises this is a very good thing.
Here is why Relay matters: