4 ms·
I write React every day and don't know what you're referring to – you can just call fetch() in a lifecycle hook and be done with it, just like in any other fram
by exogen 8y ago
I write React every day and don't know what you're referring to – you can just call fetch() in a lifecycle hook and be done with it, just like in any other framework.
But mostly I'm curious how your point relates to this blog post. Maybe you can clarify? The stuff they're doing with Apollo here that potentially comes across as boilerplate also gets query batching, caching, refetching, etc. for free (in addition to the fancy stuff they also talk about like automatic mocks). It's not like they're "just sending a request." Maybe you can show me how you do all that in another framework without some setup/wrappers/etc.?
- EduardoBautista 8y agoThings Ember Data's `findRecord` does: * Checks if you already have the resource to prevent sending an unnecessary request (can be forced) * Retrieves the resource based on a convention for the URL * Parses the JSON based on a convention * Stores the resource in the "store" for use in the app Batching is also very simple thanks to a plugin from Netflix: https://github.com/Netflix/ember-batch-request https://github.com/Netflix/ember-batch-request The reason the Ember community doesn't talk about any of this stuff is because, from the developers perspective, nothing interesting happens, which is why developer productivity is high in Ember.
- exogen 8y agoWhy would a UI framework know anything about records? Keep in mind that it's explicitly not React's goal to know anything about requests, routing, records, data, or anything like that. That's why you hear React people talking about how they achieve this stuff. Ember is a framework with a much larger scope, while React is a view layer.
- EduardoBautista 8y agoEmber Data can be used separately from Ember itself. In fact, the official documentation treats them as if they are. It's even a separate project on GitHub: https://github.com/emberjs/data https://github.com/emberjs/data
- exogen 8y agoIf even in Ember-land it's an entirely separate package, then why make the comparison to React at all..? (Ember + Ember Data) is more like (React + Apollo) then, no? But you're just comparing it to React without anything else.
- EduardoBautista 8y agoMy original comment said "React ecosystem", not just "React". Apollo is part of the ecosystem.
- exogen 8y agoHere's what just sending a request looks like with React + Apollo: https://codesandbox.io/s/q71px7njrw https://codesandbox.io/s/q71px7njrw Which boilerplate do you take issue with? There are a couple imports you might find ugly, I suppose. Most likely though the blog post we're talking about isn't a good impression of what "just making a request" looks like. :)
- lhorie 8y agoThis assumes a GraphQL backend though. A lot of React shops still use a combination of redux and REST APIs, which are admittedly a tad on the verbose side
- exogen 8y agoSeeing as the article under discussion is all about GraphQL, maybe the top-level comment was off-topic? Another thing to consider though, and something I've done in the past, is that you can actually embed the GraphQL resolver runtime completely on the client and easily adapt REST endpoints to it. It's pretty neat! So you can use all the benefits of Apollo without actually having a server that speaks GraphQL. This Apollo project is one such way to do that: https://github.com/apollographql/apollo-link-rest https://github.com/apollographql/apollo-link-rest (although not the strategy I used... I don't think Apollo even existed yet at the time)
- Bahamut 8y agoJust a counterpoint, but we've had a lot of pain with Ember, especially Ember Data, with only senior developers working on an app - figuring out the right areas to modify to implement a feature/bug fix was unnecessarily difficult, and some of the recommendations we got from those closely aligned with Ember (including from a former core dev) from a maintainability perspective were highly suspect. We ended up switching to React by rewriting the Ember app in a few weeks and moving significantly faster as a team, gaining more flexibility & better abstractions (which we had to write, but it was not a problem with our engineers' quality). Since then, my whole organization has only written new UIs using React to my knowledge. I personally would rather use Angular (latest) or React than use Ember again. I do appreciate some of the things Ember has brought to the ecosystem though like a robust CLI ala Rails, but I think the routing convention needs more flexibility and Ember Data needs some love to fix the ease of getting into some buggy situations.
- dbbk 8y agoI’m a big fan of Ember but Ember Data is just completely unusable for me once you start getting into relationships. Say you have a blog post with many comments. Creating a new Comment ends up sending an UPDATE request to the Post model with ALL the comments in an array. It’s crazy.