Select fragment as observable from the store

[altschuler]

Using Apollo for Angular 2, I'm trying to find a way to reactively select entities from the cache/store. It's basically readFragment but as an observable (watchFragment maybe?). watchQuery will not work as I don't want to watch an actual query.

As far as I could tell readFragment only enables a single immediate lookup into the store, not an observable result. I tried looking into the ApolloStore, but could only find the getState and dispatch, no select or similar.

Am I missing something? :-)

Edit: I'm certain this would be possible by using my own NgRedux store and just select data from that, but I'm wondering whether there's a way to select directly through Apollo (internally it must happen somehow).

Edit 2: I've achieved this with a "custom" NgRedux store and it works perfectly. However, I still think watchFragment would be a valid addition to Apollo :-)

Edit 3: So, it actually does not work perfectly like this, because I'm only getting the entity itself from the store, not any related entities that might exist on the fragment.

[helfer]

Hey @altschuler, that's an interesting idea. Can you tell me what your use-case is?

You're right that currently there's no function that lets you do this directly, but if you want to make a PR to add a watchFragment function, we'd definitely be open to that.

Right now, I think you can get exactly what you want by using a custom resolver. You can make the custom resolver take one argument (the store key) and simply return the reference object, below which you can select the fragment. Here's an example:

const client = new ApolloClient({
  customResolvers: {
    Query: {
      readFragment(_, args) {
        return toIdValue(args.id);
      },
    },
  },
});

const QUERY = gql`
query {
  readFragment(id: "myId") {
    name
    id
    age
  }
}`;

const observable = client.watchQuery(QUERY);
observable.subscribe( ... );

Let me know if it works!

[altschuler]

Cool, thanks a lot, that might work. I went for NgRedux to get notified when a change has occured and the readFragment to get the actual full fragment. It might be quite a performance overhead so will have to measure. Using the technique you mention, would you say that, performance-wise, it's something that's suitable for having potentially hundreds or watchQuery going at a time?

Use case is that I've got a document from the apollo server which I need to manipulate (it's an editor thing). This document contains references to a lot of other entities which I don't want to be part of the editing process, so I'm just using their IDs to fetch the fragments since I know they're in the store. I also need to have these fragments up to date with the store because they can be updated via mutations from anywhere. It's a bit complicated to explain and there might be a cleaner solution, but the gist is that I've got ID's of entities that I need the fragments of and I need to "watch" them, not one-off read.

As for the PR, I would like to have a stab at it. Any pointers? I've had a look around but there's a decent amount of code to digest. My hunch is that it would need to be implemented in the DataProxy?

[jbaxleyiii]

@helfer would you be able to help point @altschuler in the right direction here?

[stale]

This issue has been automatically marked as stale becuase it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[helfer]

Hey @altschuler, sorry for the radio silence on my part. Are you still interested in this? As far as I know Apollo hasn't yet been optimized to watch lots (ie. hundreds) of queries at the same time, so the performance probably wouldn't be good. However, it might be worth measuring in the first place to know where we're really at.

[altschuler]

@helfer No worries! I'm still quite interested, I think it'd be a nice addition, I can image a few use cases if it can be done in an efficient way. Regarding the performance of watchQuery I never measured it since I never went with that solution, but it somehow feels like the wrong approach to "wrap" simple fragment lookups with proper query bells and whistles

[helfer]

Ok, great! I'm not sure what the latest state is of the new store API that you'd have to write against, but maybe @jbaxleyiii can fill us in!

[stale]

This issue has been automatically marked as stale becuase it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[stale]

This issue has been automatically closed because it has not had recent activity after being marked as stale. If you belive this issue is still a problem or should be reopened, please reopen it! Thank you for your contributions to Apollo Client!

[ntziolis]

Is this possible by now?