|
|
|
|
|
|
by Oddskar
1699 days ago
|
|
|
> For example, I have implemented layers where GraphQL queries feed into mobx to manage some additional application state that never persists. Not sure what you want to say with this because it sounds like you used Mobx for state management in that case. Or do I misunderstand you? > I additionally think that it's a very light layer in terms of managing state According to bundlephobia: React + DOM = ~42KB Gzipped @apollo/client = 39KB Gzipped For reference redux + redux thunk is like 2KB Xstate is less than 20KB > what I really mean is knowing when the client-side cache needs to update Aha, and that sounds sensible. I agree. There are lots of other things in Apollo though that you apparently aren't using. |
|
|
> Not sure what you want to say with this because it sounds like you used Mobx for state management in that case. Or do I misunderstand you?
Yes, I kind of botched it, but it's my point - GraphQL as state management can mean a lot of things. It can mean Apollo, client-side cache invalidation, use of subscriptions, etc.. I think that I found your statement of GraphQL breaking down above moderate complexity confusing because it was unclear to me what way you meant this in.
RE: apollo client, it's interesting to see that it's large, I agree that contrasted to XState or Mobx or especially Redux it is quite large, I would be happy to see that number come down, but I also am not so scared of 40KB I can serve from cache given I'm rendering "dataflow editors" of some complexity
Finally, I agree I barely use Apollo, I find its graceful property to primarily be cache management but greatly prefer mobx for true application state management because it is blazing fast / the most efficient rendering strategy