query($count: Int) {
users(first: $count) {
name
cursor
}
}const mapStateToProps = () => ({ response: cashay.query(query, { variables: {count: 2}, component: 'HousekeeperList' }) });
I get the first two
users, but as soon as I use:setVariables(currentVariables => {
return {
count: currentVariables.count + 2
}
})
I get the error
This loops through the reqASTArgs which is always first and after, so even if i comment out the line that throws here:
if (paginationMeaning === BEFORE || paginationMeaning === AFTER) {
throw new Error(`Supplying pagination cursors to cashay is not supported. ${variables}`)
}it then throws here:
if (hasPagination === true) {
throw new Error(`Only one pagination argument can be supplied at a time. ${variables}`)
}
If I comment both out, then it all works as intended!! What are these checks doing?... and what am I doing wrong?
I've tried following the cashay-playground as much as possible.
No worries. Ps. Have you looked into Apollo Client? Seems to solve (and more) the same issues that cashay solves. Wonder what your thoughts are? http://docs.apollostack.com/apollo-client/index.html
I've only just started looking into it (and cashay) as potential solutions. First up is the amount of documentation for apollo, it's crazy detailed... no looking into source code to figure how to do "something". I like that I did not have to generate a client side schema for my graphql schema. I'm using Golang for my backend so I had to hack together a way to generate my schema via a node build step (which was less plug and play). Apollo also has support for re-fetching mechanisms.. like polling (and they will support other update solutions ie. push). Another nice touch is they have the idea of middleware and afterware, which you can use to always fetch
__typename for example, and maybe call logout if a return has status 401 in the afterware. One thing I did notice is that the way you do pagination is better. I like the idea of the EOF flag and also being able to fetch 11 docs and only display 10; having said that, they way you do pagination is a bit of "hidden magic" which might not make sense if you're using your graphql server for other clients, like native apps, as returning first n+1 might not be right.
Documentation-- I just got budget approval to hire an intern to document the entire thing :smile: you should see some good docs shortly
Client-side schema-- I do this for a couple reasons (albeit I haven't done a good job of sharing these): 1. Validation: Cashay can throw an error before you even leave the client. 2. No defensive coding: Cashay returns a document full of
null and [] synchronously so you can load partial docs. 3. Building a django-like admin page based solely on your redux store, since your store knows about TypeNames.
Refetch--
forceFetch: true. For polling, I think a TTL is a little more eloquent than a query-specific timeout (eg a User document is good for 1 hour, so any query involving a User document will refetch after that.). Doing it this way let's you use the same logic for persisting your data in local/native storage.
__typename Cashay automatically fetches this (as well as id), although I don't think I mention that anywhere :see_no_evil:
Unlike in action, where a channel (for a list of items) is subscribed to and then multiple "add" events come down the pipe for each item in the list, I am trying to reply to the subscription with an initial set of data
so the subscriber contains something like
data.objects.forEach(object => upsert(object))
cashay dispatches to redux on every item (could be 5, could be 500)
is that something we could/should debounce?
cashay is dispatching for each item, which triggers my
stateToComputed which triggers a re-render
fine if there's a couple, but if there's a lot..
in other words, don't optimize at cashay, rather optimize at ember, probably by memoizing
right now it stays "loading" indefinitely
ok, have a great night!
Hey @mattkrick, I think the setVariables function returned with a query is not doing its job correctly. You don't seem to use it in action so I guess you haven't stumbled upon the issue, but the expected behavior in my opinion is:
- either there was a previous query with the same arguments and you get a fastResponse (from the 'responses' part of the cashay store)
- or; either no such query was ever triggered or the arguments differed (in which case you wanna call the remote server, minus a bunch of things that you may already have locally)
Currently, it does not behave that way. If you have a query (an 'op' in cashay's terms) with a given key, then changing the arguments does nothing but changing the arguments in cashay's store (and calling the affiliated mapStateToProps again). One way to get my expected behavior would be to put all the variables in the key. However this destroys the very purpose of setVariables because then the variables in the store won't be synchronized with this "unique" key.... Perhaps you have good insights about this..