Some feedback

[StevenBlack]

Hi Tanner! Taking a moment here to provide feedback on this repo, and how it's organized.

I've been developing in RN for three years now, maintaining and developing a variety of projects for a customer. I'm maintaining legacy RN, and creating new apps used on mobile (with Expo) and browser apps as well.

Given the above, I hope to find a better way to handle queries because man, I wish our mix of legacy and new projects could standardize on something.

React-query looks phenomenal. But right now, I can't really tell, and finding out is going to be laborious. Here's why.

I'm having a lot of trouble distinguishing what this repo strictly provides, and the substantial scaffolding surrounding the examples.

In other words, the examples appear good, but they are all a bridge too far because of the external scaffolding required to support all these examples in a common way.

My Suggestion: this repo needs one or two dead-simple, elementary, stand-alone examples. No scaffolding, no common conveyance framework. just one or two dead-simple, trivial examples.

For example, show one get; I don't care what it is, it just needs to be over http(s). Show one post request, don't care what it is. Call out to placekitten or something. Dump what comes back in a <View /> or something. Dead simple.

I look at the examples and I'm dumbfounded. This repo's examples imports fetch from four-folders deep, which imports isomorphic-unfetch which is nominally fine, except is that demo scaffolding, or is that critical to react-query? A dead-simple demo would tell us.

I suppose what I'm saying is, it's hard to distinguish signal from noise here, and it looks like it might cost me a focused day to find out. This ought to be simple.

[tannerlinsley]

Sure, some of the examples have some cruft I would also love to remove. TBH, I took most of them right out of zeit's SWR examples and adapted them for RQ without many changes. IMO, a simple fetch or even just using axios would get the job done. In the sandbox example, we don't even do that and just mock the calls in the same file. This is among many other things that could be simplified.

All in all, I'm sorry if the existing examples are too noisy. I spent WAY more time developing the docs than the examples and I know it shows. I would happily accept any and all PRs to create new examples that are better or improve the existing ones to be more straightforward.

In the future, we are going to have a few example apps on display that use existing apis and simple structure to show how it scales both down to small sandboxes and up to large apps.

[tannerlinsley]

Feel free to mark this discussion as answered or continue to discuss if you wish.

[StevenBlack]

Thanks Tanner. I think I'll step away.

Without a bare-bones, minimum, ceremony-free usage case, I can't tell what I might be in-for.

It appears it'll take me awhile to spin-up a personal test case, which will be a 100% trial and error thing for me, just to evaluate this in an elemental, presumption-free, infrastructure-free context.

I mean, take this, fetch current temperature in NYC, dump the response in console.dir. I would have to discover where to even start, with this. Looks like, at minimum, I'd need to weave-in unfetch, which appears to be an undocumented hard-dependency for http(s) requests here.

Overall this whole thing looks so, so good though. Argh!

Good luck the rest of the way!

Closing.