6 ms·

As primarily an Ember.js user (with an interest in Elm), just looking at how many hoops people in the React ecosystem go through just to send a request just bog

As primarily an Ember.js user (with an interest in Elm), just looking at how many hoops people in the React ecosystem go through just to send a request just boggles the mind. Maybe I am in the minority, but writing boilerplate code all the time just isn't something that interests me.

testnew2 8y ago
That boilerplate has absolutely nothing to do with react.
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 ago
  Things 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 ago
    Why 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 ago
      Ember 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 ago
        If 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 ago
        My original comment said "React ecosystem", not just "React". Apollo is part of the ecosystem.
        exogen 8y ago
        Here'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 ago
aboutruby 8y ago
I also much prefer simple REST APIs, just much easier to understand among other things. (e.g. fetch("/api/users").then(...) and it's good to go)
- exogen 8y ago
  It's certainly easier to start out that way. But there are also a lot of pitfalls, that systems like what's described in the article are designed to solve. For example: let's say when component A or component B get rendered, they need to fetch users in order to show something about them. You only want to make the request if either of these components is actually rendered on the screen. What if they both get rendered? Is something going to know to reuse the inflight request so you don't have two identical requests? Or is it just naively going to make unnecessary requests? What if some other thing already fetched the user list earlier, are either of them still going to make the request anyway? Or use the data that's already there? Another example: you've got your result from the users endpoint. Now you fetch some user information from the "blog author" endpoint. Information about the same user is in both responses. What's the authoritative client-side source of information about that user now? Are you now going to potentially be displaying stale/conflicting info about that user in 2+ different places? etc. You can always just keep things simple if you want, and people in React and GraphQL land are happy to do that, too. But a lot of people are also focused on building complex applications. This is just to give you some perspective on the "why" here.
  - aboutruby 8y ago
    In my cases, for 1) and 2) the parent component would be fetching the user and passing it down to the child components.
    - exogen 8y ago
      For (1), how does the parent know whether those components will actually be rendered? Keep in mind one of the requirements was "only fetch if they're actually rendered." Presumably some other components along the way could be deciding to conditionally render them, right? For (2), the complexity is still there, just in the parent: it needs an entity store and to merge/invalidate when the same entity appears in multiple responses. So still not just a simple case of making some REST API calls.
Waterluvian 8y ago
Are you talking about thunks and action creators and whatnot? All totally optional and ideally with a future plan in mind. Just call fetch.
- xrd 8y ago
  I don't disagree with what you are suggesting. I personally prefer react over all other frameworks. And, there are many blog posts with outdated suggestions referring to the items you've referenced. Knowing which of those posts to skip over now that the proper solution has been named is what's really challenging about React (and, of course, JS in general). Probably the OP has seen two many of those posts and doesn't have the right frame of reference to know what to do, and Apollo looks like the same.
yodon 8y ago
> ... hoops people in the React ecosystem go through just to send a request boggles the mind React Hooks (currently in alpha for the next release of React) finally clean up that component lifecycle complexity I think you're referring to. Nader Dabit has a great post [0] on how to use React Hooks with GraphQL. [0]https://medium.com/open-graphql/react-hooks-for-graphql-3fa8ebdd6c62 https://medium.com/open-graphql/react-hooks-for-graphql-3fa8...
- saranshk 8y ago
  Thanks for the blog post. I was going to look for a similar thing soon enough.
bgentry 8y ago
Shameless self-promotional plug: ember-apollo-client is pretty damn easy to get started with and fits in really nicely with the Ember way of doing things :) https://github.com/bgentry/ember-apollo-client https://github.com/bgentry/ember-apollo-client
dpacmittal 8y ago
Except Apollo is for sending graphql requests, not just any request.
dorian-graph 8y ago
You can end up writing a lot of boiler plate code to send requests in Elm, FYI.

testnew2 8y ago

That boilerplate has absolutely nothing to do with react.

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 ago
Things 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 ago
  Why 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 ago
    Ember 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 ago
      If 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 ago
        My original comment said "React ecosystem", not just "React". Apollo is part of the ecosystem.
        exogen 8y ago
        Here'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 ago

aboutruby 8y ago

I also much prefer simple REST APIs, just much easier to understand among other things. (e.g. fetch("/api/users").then(...) and it's good to go)

exogen 8y ago
It's certainly easier to start out that way. But there are also a lot of pitfalls, that systems like what's described in the article are designed to solve. For example: let's say when component A or component B get rendered, they need to fetch users in order to show something about them. You only want to make the request if either of these components is actually rendered on the screen. What if they both get rendered? Is something going to know to reuse the inflight request so you don't have two identical requests? Or is it just naively going to make unnecessary requests? What if some other thing already fetched the user list earlier, are either of them still going to make the request anyway? Or use the data that's already there? Another example: you've got your result from the users endpoint. Now you fetch some user information from the "blog author" endpoint. Information about the same user is in both responses. What's the authoritative client-side source of information about that user now? Are you now going to potentially be displaying stale/conflicting info about that user in 2+ different places? etc. You can always just keep things simple if you want, and people in React and GraphQL land are happy to do that, too. But a lot of people are also focused on building complex applications. This is just to give you some perspective on the "why" here.
- aboutruby 8y ago
  In my cases, for 1) and 2) the parent component would be fetching the user and passing it down to the child components.
  - exogen 8y ago
    For (1), how does the parent know whether those components will actually be rendered? Keep in mind one of the requirements was "only fetch if they're actually rendered." Presumably some other components along the way could be deciding to conditionally render them, right? For (2), the complexity is still there, just in the parent: it needs an entity store and to merge/invalidate when the same entity appears in multiple responses. So still not just a simple case of making some REST API calls.

Waterluvian 8y ago

Are you talking about thunks and action creators and whatnot? All totally optional and ideally with a future plan in mind. Just call fetch.

xrd 8y ago
I don't disagree with what you are suggesting. I personally prefer react over all other frameworks. And, there are many blog posts with outdated suggestions referring to the items you've referenced. Knowing which of those posts to skip over now that the proper solution has been named is what's really challenging about React (and, of course, JS in general). Probably the OP has seen two many of those posts and doesn't have the right frame of reference to know what to do, and Apollo looks like the same.

yodon 8y ago

> ... hoops people in the React ecosystem go through just to send a request boggles the mind React Hooks (currently in alpha for the next release of React) finally clean up that component lifecycle complexity I think you're referring to. Nader Dabit has a great post [0] on how to use React Hooks with GraphQL. [0]https://medium.com/open-graphql/react-hooks-for-graphql-3fa8ebdd6c62 https://medium.com/open-graphql/react-hooks-for-graphql-3fa8...

saranshk 8y ago
Thanks for the blog post. I was going to look for a similar thing soon enough.

bgentry 8y ago

Shameless self-promotional plug: ember-apollo-client is pretty damn easy to get started with and fits in really nicely with the Ember way of doing things :) https://github.com/bgentry/ember-apollo-client https://github.com/bgentry/ember-apollo-client

dpacmittal 8y ago

Except Apollo is for sending graphql requests, not just any request.

dorian-graph 8y ago

You can end up writing a lot of boiler plate code to send requests in Elm, FYI.