Initial feedback: flexible but verbose?

[jrmyio]

I just scanned through the docs and just wanted to leave my first impression here.

Things look very flexible and that is great! However, it does seem like it's pretty verbose to use it.

It would be great if there would be better defaults, or some factory functions that have certain expectations on how you structure your data, thus reducing the amount of stuff a dev has to do in order to get the most common use cases.

This could be a separate library that uses this library underneath?

Anyway, maybe this is just me, but it's a bit too low level for my taste to really give it a try.

Curious what others think.

[k-ode]

Thanks for the feedback!

I initially planned createQuery to have a simpler form like this:

const MyQuery = createQuery(asyncFunction, DataModel, RequestModel)

Where both DataModel and RequestModel would default to types.frozen if not given.

Is this the sort of thing you are thinking about?

[jrmyio]

Sorry for taking so long to respond.

Yes, I am not sure if its good idea to add a lot of arguments. If the asyncFunction is really the only required thing then giving it its own argument is probably a good idea because then you don't have to pass an object at all (in the most simple case).

Since there are props like pagination and env its probably best to make the second argument all those optional props (including data and request). I agree, using types.frozen for both seems like a smart default.

Given the example:

const PostQuery = createQuery("PostQuery", {
  data: MstQueryRef(PostModel),
  request: types.model({ id: types.number })
}).actions((self) => ({
  run: flow(function* () {
    const next = yield* self.query(getPostById);
    next();
  })
}));

Your asyncFunction would be just getPostById, correct?

For data model, it would be great if you don't need to wrap it with types.model(), even more so for the request model (because it would require this always anyway?). So maybe allow both an object that describes a model, and a finished model itself.

In your proposal you are leaving out the name, if that is optional that would be great.

So

const PostQuery = createQuery("PostQuery", {
  data: MstQueryRef(PostModel),
  request: types.model({ id: types.number })
}).actions((self) => ({
  run: flow(function* () {
    const next = yield* self.query(getPostById);
    next();
  })
}));

could become something like:

const PostQuery = createQuery(getPostById, {
  data: MstQueryRef(PostModel), // or maybe even data: PostModel ?
  request: { id: types.number }
});

I do find the word data a little generic, what about response or result?

When it comes to useQuery(MessageQuery, { request: { id }, });, would it also make sense to think about an API that allows the QueryModel to be done inline?

As a user you are most likely already taking the asyncFunction from some sort of Agent or API object, adding even more astractions or files to do a single call for data might feel a little over the top.

On a last note, I've been wondering if it wouldn't be smarter to make this an add-on on react-query. Given the fact that react-query has become an industry standard and is well maintained, it might reduce the amount of work that has to be done in mst-query. A lib like this suddenly not being maintained anymore would be my primary concern, whereas if its an add-on on top of react-query it will probably continue to benefit from all react query updates without breaking.

This could also help with bundle-size, using just react-query alongside, and removing the double configuration on top of your react tree. And finally, it could help adoption. I doubt many people are willing to go all in on mst-query when they already have react-query in their app.

[k-ode]

Thanks for taking the time to write these excellent suggestions! I'll consider this for future development.

About React Query: mst-query is actually not that large. A lot of the heavy lifting is already done by mobx and mobx-state-tree. I tend to think of mst-query more of a query library for mobx/mobx-state-tree, and not a React Query clone. Also, the main value for me with this project is the reactive and normalized cache, and this would be difficult to implement on top of React Query I think.

Mobx-state-tree is maintained but has not changed much in recent years, and my aim is to achieve similar stability with mst-query.

For a mobx-state-tree integration with react-query, you can checkout this article: https://dev.to/lloyds-digital/normalize-your-react-query-data-with-mobx-state-tree-17fa