Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we decided against GraphQL for local state management

tech.okcupid.com

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Why we decided against GraphQL for local state management

#41

Post by acemarke »

weeksie wrote: post #39
acemarke wrote: post #38

Earlier quoted context omitted.

> The problem with his style is that he parades himself as an expert but he's emphatically not an expert Erm... I've been a Redux maintainer since mid-2016. I oversaw development of React-Redux v5 and v6, wrote v7 by myself, and directed development of the hooks API in v7.1 over the course of multiple 250+-comment issue threads. I've written the Redux FAQ, "Structuring Reducers" usage guide, the "Style Guide" best pr…

Lots of blog posts, tutorials, etc. blah blah blah. How many complicated applications have you built with Redux at their center? Because that's the part that's missing from your list of qualifiers for being an expert.

Two, because I've spent the last 9+ years of my career working on the same couple apps :)

But both were pretty complex - true SPAs, no routing, lots of complex client-side state manipulation going on.

In fact, the first one is actually what inspired everything that I showed in my "Practical Redux" blog tutorial series, since I couldn't show off work stuff publicly.

But hey, if that list of stuff I've done isn't good enough for you, apparently no one in this world qualifies as an "expert" in any topic :)

Re: Why we decided against GraphQL for local state management

#42

Post by bengale »

> This gives us one of two options for our cached data: either make sure every query requests a uniquely identifying field of the data we are requesting (doesn't this defeat the purpose of requesting whatever fields we want?) or writing explicit typePolicies to tell our cache how to normalize our data.

This is the exact thought I had recently when fighting the Apollo cache.

Re: Why we decided against GraphQL for local state management

#43

Post by isakkeyten »

weeksie wrote: post #26
acemarke wrote: post #25

Earlier quoted context omitted.

I'll have to disagree with that, on multiple levels. Thunks are simply an approach for writing reusable async logic that has access to `dispatch` and `getState`, without being tied to a specific store [0]. While I do think more people would benefit from writing middleware for their own particular use cases, most people just want to have a place where they can fetch some data and dispatch an action containing the resu…

What's with the copy paste spam on every one of your posts? None of what you're saying matters in the scheme of things. You can get everything you need from const { types, actions } = createActions([ 'ACTION_NAME', ...]); Where createActions is an exercise for the reader, but shouldn't take more than a few lines. Then go about your business from there. Adding another layer of framework over the top of this stuff only…

He's been doing it for a while now. I believe he has setup some google alerts on the words 'redux | thunks | sagas' and he just brings his redux toolkit gospel along. And not just on this site, like, everywhere. Dev.to, reddit, twitter...

I've confronted him once but to no avail, I even got downvoted by the community. :)

https://www.reddit.com/r/reactjs/comments/fvuwpl/handling_si...

edit: i see that's happening to you too here lol, godspeed

Re: Why we decided against GraphQL for local state management

#44

Post by bengale »

city41 wrote: post #11

I largely came to the same conclusion, including going back to Redux. I have found using Apollo for client side state very cumbersome and even difficult. You really do need to understand their cache well, and I also dislike having to deal with things like __typename, which I feel is an implementation detail that unfortunately gets foisted onto the end developer. Sometimes __typename is a royal pain in the butt. The a…

Like when you send data to a mutation and it complains about it having a __typename field that they bloody added. Had some pain with that this week.

Re: Why we decided against GraphQL for local state management

#45

Post by weeksie »

acemarke wrote: post #41
weeksie wrote: post #39

Earlier quoted context omitted.

Lots of blog posts, tutorials, etc. blah blah blah. How many complicated applications have you built with Redux at their center? Because that's the part that's missing from your list of qualifiers for being an expert.

Two, because I've spent the last 9+ years of my career working on the same couple apps :) But both were pretty complex - true SPAs, no routing, lots of complex client-side state manipulation going on. In fact, the first one is actually what inspired everything that I showed in my "Practical Redux" blog tutorial series, since I couldn't show off work stuff publicly. But hey, if that list of stuff I've done isn't good…

You've worked on two apps. Besides that you've been a part of the evangelist ecosystem for a tremendously simple framework. You are not what I could call an expert in using Redux.

You are almost certainly an expert in Redux's internals but that's not what we're discussing. In fact the root of the problem is exactly that you've conflated one for the other.

Re: Why we decided against GraphQL for local state management

#46

Post by acemarke »

weeksie wrote: post #45
acemarke wrote: post #41

Earlier quoted context omitted.

Two, because I've spent the last 9+ years of my career working on the same couple apps :) But both were pretty complex - true SPAs, no routing, lots of complex client-side state manipulation going on. In fact, the first one is actually what inspired everything that I showed in my "Practical Redux" blog tutorial series, since I couldn't show off work stuff publicly. But hey, if that list of stuff I've done isn't good…

You've worked on two apps. Besides that you've been a part of the evangelist ecosystem for a tremendously simple framework. You are not what I could call an expert in using Redux. You are almost certainly an expert in Redux's internals but that's not what we're discussing. In fact the root of the problem is exactly that you've conflated one for the other.

I know I'm feeding a troll here, so last response.

I've looked at hundreds of other codebases, ranging from beginner apps to complex enterprise-level apps. I've talked to thousands of people who are using Redux in many, _many_ different ways, and catalogued hundreds of libraries people have made to add on to Redux. I _know_ how people are using Redux in practice, and what kinds of problems they're running into.

I'm quite serious when I say I'd like you to write up an issue with some specific concrete feedback listing your concerns with how we currently teach Redux and recommend people use it, especially since I'm working on an ongoing revamp of our core docs. I obviously can't guarantee any _changes_, but I'm very interested in having substantive discussions in a more suitable venue than HN comments.

Whether or not you choose to take me up on that is up to you.

Re: Why we decided against GraphQL for local state management

#47

Post by VintageLight »

wdb wrote: post #32

Personally, I enjoy using React Context for some stage, and let data handling/caching be handled by React Query and it works lovely. So much simpler than Redux

Agreed. React Context wonderfully handles state that will only ever live locally/"on the client".

I don't mind Redux for local state management, but it's a little overkill if you aren't using it already to handle API state.

Using Apollo on the client side makes me want to pull my hair out though.

Re: Why we decided against GraphQL for local state management

#48

Post by jackewiehose »

weeksie wrote: post #33
vosper wrote: post #29

Earlier quoted context omitted.

I don't think this comment is fair - acemarke does show up in virtually every Redux discussion on HN, but I've found his comments to be reasonable and helpful. I don't think labeling them as spam is justified. He makes an effort to address specific points, doesn't get defensive or angry, and seems to take criticism and feedback seriously. He has responded to my own critiques of Redux in a reasoned way. I think that i…

I see it as someone clout-chasing for their framework. A framework that promotes questionable practices. Framework developers and working engineers have diverging interests. The problem with his style is that he parades himself as an expert but he's emphatically not an expert. He's a guy with an agenda to push his open source framework. I understand where the bias toward politeness comes from, but that makes groups l…

> Framework developers and working engineers have diverging interests

how is that?

Re: Why we decided against GraphQL for local state management

#49

Post by consolenaut »

I'm doing a big Apollo/GraphQL piece for the BBC for a lot of the same reasons OP lists, and have run into pretty much all the same issues with Apollo that OP has.

Its rough because Apollo does so much for you, its wonderful, but there are so many sharp edges and pitfalls - from the buggy devtools to the lack of/incorrect docs, major unanswered github issues & constant API breaking changes even on patch/minor version bumps, its been an uphill struggle all the way. All that said, it still seems like the best tool for the job, Relay still has a huge learning curve & has already had two major branches with no refactor path between (Classic/Modern) & the numerous other implementations all lack things Apollo gives you for free.

If your usecase is simple, using Apollo to query a GQL server with a well defined schema doing little to no client state handling it can be pretty straightforward, but the complexity ramps up crazy quick as soon as you start messing around with caches or persistence or local state.

The Apollo folks seem to have a handle on things but hopefully I/we can start contributing back, if not with feature work than with documentation

Re: Why we decided against GraphQL for local state management

#50

Post by acemarke »

isakkeyten wrote: post #43
weeksie wrote: post #26

Earlier quoted context omitted.

What's with the copy paste spam on every one of your posts? None of what you're saying matters in the scheme of things. You can get everything you need from const { types, actions } = createActions([ 'ACTION_NAME', ...]); Where createActions is an exercise for the reader, but shouldn't take more than a few lines. Then go about your business from there. Adding another layer of framework over the top of this stuff only…

He's been doing it for a while now. I believe he has setup some google alerts on the words 'redux | thunks | sagas' and he just brings his redux toolkit gospel along. And not just on this site, like, everywhere. Dev.to, reddit, twitter... I've confronted him once but to no avail, I even got downvoted by the community. :) https://www.reddit.com/r/reactjs/comments/fvuwpl/handling_si... edit: i see that's happening to y…

Honestly, the only alert I have is a Tweetdeck search for hashtag `#redux`.

Other than that, I just spend too much time on social media :)

Post reply on HN