Hacker News Reader

Comment by bnchrch | Hacker News Reader

Redux is far from dead but I do think apollo-link-state has the ability to take its crown if GraphQL continues to gain wide adoption; which I believe it will.

Though it's a very new library (Dec 2017) so it has a long way to catch up in terms of tooling and support.

I just happened to write an article on apollo-link-state for those who are curious about how it's used.

https://hackernoon.com/setting-up-apollo-link-state-for-mult...

View on HN

So I haven't actually used GraphQL at all, although I've sat through a bunch of talks on it and am pretty familiar with the concepts. That said, I have to say that the examples I'm seeing for setting up link-state mutations don't look like they're particularly concise.

Given that "boilerplate" is a typical complaint about Redux (which can itself be handled with whatever abstractions you want to put in place), I'm not seeing the appeal here. Is it just a case of "we're already using GraphQL, so GraphQL all the things" ? (Note that the article itself doesn't use the word "boilerplate", I'm just pointing at that as a reason I've seen people throw out for wanting to move to link-state.)

apollo-link-state would almost certainly be considered a hack if it was made by anyone else other than the Apollo team. Just the fact you need to manually specify the __typename field feels wrong to me. But I do have hopes that Apollo will grow and improve here, and apollo-link-state will likely evolve into an elegant tool.

I felt the __typename was really awkward too, but Peggy Rayzis (of the Apollo team) told me awhile ago that they're working on removing that requirement, if it hasn't been done already. I don't think it's anywhere near as feature rich as MobX for local state though, so I use Apollo for remote data and MobX for local.

A GraphQL specific state management library can't take the crown from a generic state management library. By the time GarphQL gains "wide adoption" (like REST) we'll be 2+ frameworks past React.

Thats a good point! but here you have to consider where "new" development is taking place. New articles and tutorials as well. Php is still technically king right now if we ignore this.

Love Apollo - they're a great team with many of great open source offerings. Apollo link state excites me because it unites remote and local data under a single source of truth. As a long time Redux fan, it will be nice to have one less layer and dependency to debug. GraphQL as a uniform layer for accessing that source of truth is in my mind, a Redux-killer.

Just wanted to say thank you for the heads up. I've been taking a react course on udacity where redux is super baked in so im not being exposed to many things like apollo-link and graphQL, I learned a lot from your post :)

Oh man! This is the best feedback to receive! If you have any more questions feel free to DM me anytime!

apollo-link-state in its current form is incredibly simple. I am using it in two apps right now and it fits their needs well enough. But I have another app that I would never consider using apollo-link-state in, rather it uses redux. This third app has far more complex client side state that I just can't imagine apollo-link-state handling well at all.

I actually think mobx-state-tree is my favorite of them all, but I shy away from it due to its performance issues. When they solve that, I will likely adopt mobx-state-tree quite often.

Reply on news.ycombinator.com