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

61–70 of 99 posts

Re: Why we decided against GraphQL for local state management

#61

Post by siquick »

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…

They are one of the maintainers of Redux Toolkit (which has made Redux so much nicer to work with)

Re: Why we decided against GraphQL for local state management

#62

Post by [deleted] »

pier25 wrote: post #36

State management is one of the reasons I moved away from React and Vue. You need a lot of machinery and plumbing to do something that should be really simple. MobX is probably the best way I've found to manage reactive state with React, Inferno, etc, but still, it's a huge piece of of software for just this purpose. I first moved to Mithril because it doesn't need reactivity. You solve the same problem than React/Vue…

[deleted]

Re: Why we decided against GraphQL for local state management

#63

Post by darksaints »

pier25 wrote: post #36

State management is one of the reasons I moved away from React and Vue. You need a lot of machinery and plumbing to do something that should be really simple. MobX is probably the best way I've found to manage reactive state with React, Inferno, etc, but still, it's a huge piece of of software for just this purpose. I first moved to Mithril because it doesn't need reactivity. You solve the same problem than React/Vue…

That's almost exactly the path I've gone down, and svelte is something I've been seriously researching for a couple months now.

I have a nagging problem that keeps coming back to me though. The declarative state model is the holy grail for UI design, but if you try to mix in any form of imperative logic, it all falls apart. All of a sudden you need to understand and plug into poorly documented and opaque component lifecycle APIs in order to insert your imperative code and have it work correctly. And that really messes up the nice clean solution, making it look more like a chimera of two state models.

Some of that is fixed by libraries that create components native to your framework of choice, implementing the appropriate lifecycle hooks as necessary. But now you're relying on a library that adapts one library to another library, and now you've got a dependency sync problem on top of it all.

It wouldn't be such a problem if there weren't so many extremely useful libraries that depend on imperative code. Personally, I've run into massive problems trying to use D3, Leaflet, and Bootstrap, as well as a handful of others. I'm sure there are thousands more.

Not trying to take away from your point. When these declarative state models work well, it's a beautiful thing to behold. But there's always some point where the abstraction leaks.

https://svelte.dev/tutorial/onmount

https://reactjs.org/docs/state-and-lifecycle.html

https://blog.logrocket.com/introduction-to-vue-lifecycle-hoo...

https://mithril.js.org/lifecycle-methods.html

Re: Why we decided against GraphQL for local state management

#64

Post by kevan »

pier25 wrote: post #36

State management is one of the reasons I moved away from React and Vue. You need a lot of machinery and plumbing to do something that should be really simple. MobX is probably the best way I've found to manage reactive state with React, Inferno, etc, but still, it's a huge piece of of software for just this purpose. I first moved to Mithril because it doesn't need reactivity. You solve the same problem than React/Vue…

>> If you don't know what you're doing you will shoot yourself in the foot.

Can confirm. My team of mostly fullstack devs that prefer backend ran into lots of issues with too much freedom in Mithril.

Re: Why we decided against GraphQL for local state management

#65

Post by orange8 »

jackewiehose wrote: post #48
weeksie wrote: post #33

Earlier quoted context omitted.

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?

A framework tends to want to capture or serve all possible use cases, while app developers want to serve a single, specific use case.

Re: Why we decided against GraphQL for local state management

#66

Post by orange8 »

acemarke wrote: post #46
weeksie wrote: post #45

Earlier quoted context omitted.

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 q…

Simplify. Less is more.

Re: Why we decided against GraphQL for local state management

#67

Post by andrewingram »

consolenaut wrote: post #49

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…

That Relay rewrite was over 3 years ago though, and it’s been pretty stable since (the hooks API is coming “soon” but shouldn’t break compatibility). And there was an upgrade path, there was an intermediate compat version which let you incrementally upgrade.

The learning curve isn’t that really that steep, it’s just made artificially so by the poor docs. It’s unfortunate that the Relay team doesn’t really prioritise getting new users, because it’d motivate them to explain things better. But there’s not actually that much to learn, you can be up and running and productive with it pretty quickly.

Re: Why we decided against GraphQL for local state management

#68

Post by openfuture »

pier25 wrote: post #36

State management is one of the reasons I moved away from React and Vue. You need a lot of machinery and plumbing to do something that should be really simple. MobX is probably the best way I've found to manage reactive state with React, Inferno, etc, but still, it's a huge piece of of software for just this purpose. I first moved to Mithril because it doesn't need reactivity. You solve the same problem than React/Vue…

> should be really simple

Ummm... no, state management is pretty much the only hard problem in programming.

Re: Why we decided against GraphQL for local state management

#69

Post by city41 »

deckard1 wrote: post #56
crooked-v wrote: post #20

Earlier quoted context omitted.

Having used Redux for some elaborate stuff (in particular, a web app that used a couple of KB of info in Redux to generate an extremely dynamic UI, with diff-style data changes via Websockets inserted in realtime), honestly, the biggest problem I've seen with Redux use is just... people using it for things when they shouldn't. This is most glaring for the whole "do a GET and store it in Redux" thing, where if there's…

> people using it for things when they shouldn't I know people that advocate putting everything in redux. They are quite serious about this. Then you end up with reselect everywhere and the whole goddamn universe is memoized. No one seems to know how React renders (or re-renders), so memoize everything! Yes! That's the ticket. The overuse of Redux and the React hook brain damage stems from the tide finally turning ag…

I pretty much totally agree. FWIW, I do think there might be some good things on the horizon. Rome has a lot of potential, as do Remix and Svelte. We'll get past this :)

Re: Why we decided against GraphQL for local state management

#70

Post by city41 »

consolenaut wrote: post #49

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…

Are you sure you like Apollo? I ask because your comment says it's wonderful, but then gives a lot of reasons as to why it's not. I don't like Apollo on the client (no issue with it server side). I feel the sharp edges and pitfalls are numerous and it's a lot of boilerplate to get anything off the ground. To be totally fair to Apollo, I'm also not sure the projects I worked on really needed or benefited from GraphQL on the whole, so...
Post reply on HN