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

31–40 of 99 posts

Re: Why we decided against GraphQL for local state management

#31

Post by weeksie »

acemarke wrote: post #28
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…

Or, with `createSlice`, you get the action creators for free with your reducers: const todosSlice = createSlice({ name: 'todos', initialState: [], reducers: { addTodo(state, action) { const { id, text } = action.payload state.push({ id, text, completed: false }) }, toggleTodo(state, action) { const todo = state.find(todo => todo.id === action.payload) if (todo) { todo.completed = !todo.completed } } } }) export const…

I see what you’re doing there. I also see why you think it’s a good idea. "How the community" uses redux is badly. I guess congrats for reinforcing that at scale. Gives me some more hours to bill when I run across the next ratsnest.

Re: Why we decided against GraphQL for local state management

#33

Post by weeksie »

vosper wrote: post #29
weeksie wrote: post #24

Earlier quoted context omitted.

Man I wish you’d quit spamming every redux thread with this stuff. You’re not solving any problems, you’re just promoting your framework.

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 like HN susceptible to this kind of pretense to authority. He's actively making working developers' lives worse by promoting this stuff and it's frustrating.

Perhaps I shouldn't give a shit.

Re: Why we decided against GraphQL for local state management

#35

Post by Udik »

crooked-v wrote: post #20
city41 wrote: post #17

Earlier quoted context omitted.

You certainly have more experience and context than me. But my experience with Redux over the years is there was so many ways to do it leading to a lot of uncertainty. Do you use a switch statement or something like redux-actions? Do you use the duck pattern, where do all these things live in the codebase? What package do you grab for async actions? Are actions 1:1 with DOM events, or are they more like a state machi…

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…

So what would be your guesstimate on the percentage of redux uses in the wild that are unnecessary and just introduce complexity or boilerplate instead of providing a benefit?

Re: Why we decided against GraphQL for local state management

#36

Post by pier25 »

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 et al in just 10kB. No need for an external router or a state management library. Your state is just vanilla JS. Mithril doesn't need to know when a particular piece of state has changed, it just tries to re-render everything and the vdom takes care of the rest. The performance is comparable to Vue 2 and React [1] but the DX is lightyears ahead. It's a sushi chef knife though, you really gotta know what you're doing[2].

Now I'm using Svelte because it's even better. It does have reactivity but the compiler just figures out the dependency graph so you don't need to ship a huge thing like MobX to do that at runtime. You also write a fraction of the code compared to all the other frameworks I've used which is Svelte's best feature. This compiler approach is a game changer IMO.

[1] https://krausest.github.io/js-framework-benchmark/current.ht...

[2] What I meant by this is that since your app is essentially vanilla JS you're on your own to architecture the thing. If you don't know what you're doing you will shoot yourself in the foot.

Re: Why we decided against GraphQL for local state management

#37

Post by acemarke »

Udik wrote: post #35
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…

So what would be your guesstimate on the percentage of redux uses in the wild that are unnecessary and just introduce complexity or boilerplate instead of providing a benefit?

FWIW, my current estimates are that roughly 50% of all React apps use Redux.

I'm gonna go out on a limb and guess that maybe 1/3 of those Redux-using apps probably aren't really benefiting from Redux (things like using it _just_ to avoid prop-drilling when you could just use Context, writing reducers that are nothing more than `return action.payload` with no real logic, etc).

We've always had an entry in our FAQ section that gives some advice for when it might make sense to put a particular piece of state into Redux vs keeping it in component state. As I rewrite the Redux docs piece by piece, I'm trying to add some additional clarification and emphasis on when you should actually consider using Redux overall.

Re: Why we decided against GraphQL for local state management

#38

Post by acemarke »

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…

> 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 practices page, almost all of the Redux Toolkit docs, and the new 25K-word "Redux Essentials" real-world tutorial.

I've written about 150K words of Redux-related blog posts, including tutorials, history, technical architecture, and best practices.

I've given multiple conference talks on how Redux works and how to use it.

Even if you don't agree with the approaches I'm recommending that folks use...

if _I_ don't qualify as an "expert" on this topic, who _does_? :)

If you have actual substantive technical arguments for other approaches we should be recommending, please feel free to open up an issue to discuss them. I'm genuinely always interested in ways we can make it easier for people to learn and use Redux.

Re: Why we decided against GraphQL for local state management

#39

Post by weeksie »

acemarke wrote: post #38
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…

> 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.

Re: Why we decided against GraphQL for local state management

#40

Post by claydavisss »

vosper wrote: post #27
claydavisss wrote: post #13

I would definitely encourage all of my competitors to use GraphQL. Nothing like getting a free six-month lead. That's two months they spend learning GraphQL, two months introducing a mystery-meat binding layer and learning that, and two months debugging it all and pulling their hair out. And no, using a giant third-party lock-in toolkit like Hasura or Apollo is not a response.

Genuine question: What technologies / techniques are you using while your competitors flounder around with GraphQL?

REST and JSON because arbitrary querying is a huge YAGNI.

That said, the presence of GraphQL is a great signal that a team is infested with architecture astronauts, so I suppose it has its uses.

Post reply on HN