GraphQL/Relay Wins. Flux/Redux Considered Harmful | Hacker News Reader

Redux Considered Harmful

gist.github.com

7 pointsilostmykeys12 comments

"Flux considered harmful" That is way too strong - GraphQL handles server/client data sync, we still need a pattern for client/ui state, they are mostly orthogonal concerns. UIs aren't stateless, there's more to it than just transacting every state change directly to the server. It is a very narrow class of UIs for which that could work.

Exactly, why does everybody forget about UI state like animations, etc that are never persisted to the server? This is a huge swath of what makes up an app and you need to be able to handle it

Ephemeral UI state belongs to component local state.

I disagree, I've come across several cases where front-end-only state need to be shared by components not naturally sharing some common parent component in which the state should reside.

Good point, but that'll be covered by Relay in near future, and is worth tolerating for now via temporary hacks. The RelayJS team is aware of its importance. Updated gist:

https://gist.github.com/idibidiart/49a095b6bc528638f34f

That's good to know, thanks for pointing it out!

Ephemeral UI state belongs to component local state.

Real times streams aren't really meant to be handled by Flux/Redux or GraphQL. I should have said that GaphQL/Relay handles 80% of cases better than Flux/Redux! The rest require a different approach. Thoughts?

> UIs aren't stateless

i would agree that this is the traditional perspective.

i'm not convinced this is necessarily the case; there may be other ways to look at it. it could be that the ui "value" is the output of a series of functions, and that what might look like a "state" change is really a "new" ui being rendered.

(maybe this is what "frp" gives us, or perhaps "immediate mode gui" that sometimes pops up in game development circles; but i'm not very familiar with either.)

It is always the case. Even if you model app state in a functional way, the state is still somewhere, for example a haskell program may be pure but only because it pushed the unsafePerformIO call into the runtime. UIs always have additonal state that is not modeled in the backend, we can only reduce the surface area of code that is stateful, but we can't outright remove it, it is essential complexity in all UIs.

The title "GraphQL/Relay Wins. Flux/Redux Considered Harmful" is obviously clickbait. Relay is clearly superior to Redux/Flux for data fetching and object storage, and that isn't shocking to anyone who has looked into both of them. But Relay isn't there yet (Relay is soon going to bring time travel, has no way to manage local state, etc). With redux coming in at 2kb, there's no reason no to use both relay & redux. This isn't about winning, and Redux is by no means obsolete (yet).

Be forewarned: this is the definition of Giant Wall of Text.

Why on earth would someone write this in a Github gist? Just use one of the billion blogging platforms out there or Github's own pages feature.

GraphQL is great if you are primarily producing native apps with multiple versions coexisting simultaneously. For web applications, it is needlessly verbose.

Relay sounds interesting. I expect that a lot of its good ideas will be replicated by the community in more light-weight, less opinionated libraries.

Reply on news.ycombinator.com