Question: How to use computed properties if Models don't exist?

[optikalefx]

Hi Guys, Sorry for asking here, I looked for a slack room and didn't find one.

I see that this is a full Ember Data replacement. My question is that if that is the case, models in the model folder are no longer used. How do you then have computed properties that used to be on model?

For example, I used to have a Person model. And when data came down from the server it was of type Person. And therefore a fullName computed property could exist.

If no models exist in this apollo-client, how can I then ensure that data that comes back from GraphQL is of the right type to have all of it's needed CPs?

Thanks!

[bgentry]

For the most part, I rely on computed properties in my components. There's a small bit of duplication with that but generally not much.

In the few cases where that really wouldn't have worked well, I just added my own model class using Ember.ObjectProxy:

app/models/my-model.js

export default ObjectProxy.extend({ computedsHere });

Then in my route model(), I do something like:

    return this.get("apollo")
      .watchQuery({ ... })
      .then(result => {
        return RSVPPromise.resolve(
          result ? MyModel.create({ content: result }) : result
        );
      });

I would love to have an easier & more automatic way of doing this but it's not something I have the time to add. Contributions welcome :)

If others have their own approaches, feel free to chime in. I'm closing this since it's not an actual issue.

[josemarluedke]

I have the same question. This is the one of the main concerns I have of using apollo with Ember apps. I would love if other people posted how they solve this concern.

@bgentry Do you have any ideas of how would you make that more automatic, or more similar to Ember Data?

In addition, I'm curious to know how people do testing in a large app, do you just mock the data inline in the test? Isn't there a better and more sustainable way to do it?

[christophermlne]

I realize this is an older thread but I just stumbled across a possible solution to this problem using a built-in Apollo feature: https://www.apollographql.com/docs/react/why-apollo.html#combine-data

I'm just going to paste the relevant paragraphs from the Apollo docs in case the link breaks in six months:

Combine local & remote data

Thousands of developers have told us that Apollo Client excels at managing remote data, which equates to roughly 80% of their data needs. But what about local data (like global flags and device API results) that make up the other 20% of the pie? This is where apollo-link-state comes in, our solution for local state management that allows you to use your Apollo cache as the single source of truth for data in your application.

Managing all your data with Apollo Client allows you to take advantage of GraphQL as a unified interface to all of your data. This enables you to inspect both your local and remote schemas in Apollo DevTools through GraphiQL.

const GET_DOG = gql`
  query GetDogByBreed($breed: String!) {
    dog(breed: $breed) {
      images {
        url
        id
        isLiked @client
      }
    }
  }
`;

With apollo-link-state, you can add client-side only fields to your remote data seamlessly and query them from your components. In this example, we’re querying the client-only field isLiked alongside our server data. Your components are made up of local and remote data, now your queries can be too!

Having said that, I probably would lean toward keeping local state in components or services.