Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Roger Chapman
    @rogchap
    my query is simple:
    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
    Roger Chapman
    @rogchap
    Not quite sure what the error means as the after arg is added by cashay and then complains that is called after
    Roger Chapman
    @rogchap

    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.
    Roger Chapman
    @rogchap
    @mattkrick
    Matt Krick
    @mattkrick
    oh gosh, that definitely sounds like a regression! i haven't been keeping the playground as up to date as I should, I've been way too focused on the subscriptions for a project at work. I'll fix that up this weekend. Thank you @rogchap!
    Roger Chapman
    @rogchap
    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
    Matt Krick
    @mattkrick
    I'm very interested in what problems Apollo solves that cashay doesn't. Could you elaborate?
    Roger Chapman
    @rogchap
    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.
    Matt Krick
    @mattkrick
    Awesome feedback, thank you @rogchap!
    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.
    Matt Krick
    @mattkrick
    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:
    Wout Mertens
    @wmertens

    Curious about this edge case:

    List of Lists (eg GraphQLList(GraphQLList(Foo))). I can't think of a good reason to ever do this. Storing a 2D graph like this is wrong.

    Is only this not supported, or every list with objects that have child lists?

    Matt Krick
    @mattkrick
    just this. If the latter example works perfectly :wink:
    Dustin Farris
    @dustinfarris
    Just found cashay on Gitter :-) Howdy, folks!
    Dustin Farris
    @dustinfarris
    So in testing @live subscriber, I am sending back an initial set of data for the initial render.
    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?
    Matt Krick
    @mattkrick
    yo! sorry i'm late to the party, apparently gitter logged me out & i wasnt getting notifications
    Dustin Farris
    @dustinfarris
    hey matt, no worries, just sent that a few hours ago
    Matt Krick
    @mattkrick
    ah so you're talking about sending the current state of a text area or something?
    Dustin Farris
    @dustinfarris
    @mattkrick right, or just a list of objects in my case
    Matt Krick
    @mattkrick
    so your client framework is/should be performant enough to handle per-keystroke updates, but if you have multiple clients writing to the same field, then it does get frustrating since it's last-write wins
    Dustin Farris
    @dustinfarris
    well this is more about re-renders
    Matt Krick
    @mattkrick
    ah, then nah, no debounce necessary
    Dustin Farris
    @dustinfarris
    if i have a list of objects
    {id: "1", title: "Post 1"}
    {id: "2", title: "Post 2"}
    ...
    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..
    Matt Krick
    @mattkrick
    so at a higher level, this is a view-model concern, not a model concern
    in other words, don't optimize at cashay, rather optimize at ember, probably by memoizing
    Dustin Farris
    @dustinfarris
    right, makes sense
    Matt Krick
    @mattkrick
    hey i gotta run to dinner, ill be back tomorrow morning!
    Dustin Farris
    @dustinfarris
    also, while i have you. are you open to a PR that changes a cached response status to "subscribed" if it is a @live query?
    right now it stays "loading" indefinitely
    ok, have a great night!
    Dustin Farris
    @dustinfarris
    @mattkrick any thoughts on :point_up:?
    Dustin Farris
    @dustinfarris
    @mattkrick i am curious about use for httpTransport+priorityTransport — if my priorityTransport handles standard graphql queries/mutations, any reason i would need httpTransport? i am considering dropping it from my backend
    Maia Black
    @padmaia
    @mattkrick Is it possible to preload authenticated data for server side rendering? It seems that using a Cashay singleton would prohibit this use case, but I want to make sure I'm not missing anything.
    Maia Black
    @padmaia
    Of course it becomes clear right after I ask the question out loud. It looks like you can pass a transport to query, which should do the trick, right? I will try it out.
    theobat
    @theobat

    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..