I am trying to figure out how to use an interesting GraphQL client called gqless:
However, in the example from the Tutorial, it seems like some magic is happening in @redwoodjs/router that is invoking the methods beforeQuery, Loading, Empty and Success in src/components/PostsCell.
Is there a way for me to work around this or opt-out of this behavior?
UPDATE: I learned from this forum post of Cells that this is handled by Webpack as a build step:
So, it feels rather unlikely that GraphQL clients are going to be easily swappable. But I’m happy to be wrong about that, gqless looks really cool
So, it feels rather unlikely that GraphQL clients are going to be easily swappable.
Correct. And agreed it looks cool although I haven’t done much digging – the description/concept is definitely a headline grabber! But we’re just getting started at v0.3.2, and I can say that plug-n-play GraphQL providers is not on the near-term roadmap. (And we’re pretty excited about the things Prisma has coming this year…)
Just to keep the conversation going → this is one of the challenges of the JS ecosystem, isn’t it? So many interesting, viable tools being developed all the time. So much possibility. But the cost is then integration, configuration, and decision overhead (i.e. cognitive load). With a vision of serverless ahead of us, we’re attempting to make some solid “tech-stack” decisions that allow us to do all the integration, config, painfully-tedious-stuff, etc. so other people can focus on actually building stuff and shipping to the edge out-of-the-box.
The downside will be having to make choices about what is supported and what isn’t – which means a lot of new, interesting, viable tech won’t be included. But hopefully the upside is worth it.
You’ll have to let us know if and when that is the case. K?
I’m fully on board with standardizing on a single set of tools, no need to have that argument in this thread
I would strongly suggest taking a look at gqless, though. I saw another thread about providing first class TypeScript support:
As you work towards a 1.0, I think the idea of having explicitly declared GraphQL queries in the client will feel very redundant (and error prone) if it is instead possible to simply reference an object, access its properties, and have the GQL query constructed on the fly. That was, among other things, the magic of ActiveRecord. And it would be great to see it in RedwoodJS.
Thanks, @crabasa First off, I want to be sure to say I hope I didn’t discourage you with my thoughts/reaction! I (and the whole team) really welcome this type of suggestion and discussion. Truly. But there’s a lot of tension for us in creating an opinionated, integrated stack, with a core tension being how to a) encourage participation from people like yourself to explore the concepts and solutions while b) feeling at the same time like we’re letting a lot of people down and saying “no” quite often. Anyway, I hope you stick with us and help shape this thing into something you’re increasingly excited about as well.
Back to the topic at hand:
As you work towards a 1.0, I think the idea of having explicitly declared GraphQL queries in the client will feel very redundant (and error prone) if it is instead possible to simply reference an object, access its properties, and have the GQL query constructed on the fly.
This is a striking point. And completely agreed.
It will take a bit of work on your part (and might not work in the end), but if you want to keep exploring a Redwood + gqless POC, we’ll offer the feedback and support we can along the way (just no promises for rapid turn around). @peterp will be the most helpful here, and I’m connecting with him further if he doesn’t comment here first
Regarding “Cell magic”, that’s actually handled by Webpack and not the Redwood Router. (But you might want to skip using Cells all together if you’re trying gqless.) In general, the “Web” side is handled by Webpack at build time. And the API is handled by Babel. All our core config can be found here.
