
RIP Redux: Dan Abramovich Announces Future-Fetcher - velmu
https://react-etc.net/entry/rip-redux-dan-abramovich-announces-future-fetcher
======
chrisco255
Future fetcher is not a replacement for Redux. It's a feature they will be
adding to React later on in 2018 to allow devs to adaptively render elements
based on network performance. You can signal to React to delay rendering
specific components until an async operation is complete.

Redux is a state management layer. Future fetching does nothing to solve app-
level state management.

Gross misrepresentation of Dan's talk by this article and he made zero mention
of the React context API in the talk.

~~~
joshribakoff
[https://dev-blog.apollodata.com/the-future-of-state-manageme...](https://dev-
blog.apollodata.com/the-future-of-state-management-dd410864cae2)

What about apollo-link-state? Not a replacement either per se, but seems like
its one step closer to isomorphic (client & server side) state.

On one hand it normalizes your data & avoids thousands of lines of
boilerplate, on the other hand you lose [some] control of the underlying data
structures which is where you'd still need something like redux.

~~~
chrisco255
I love Apollo. I think it's great! It really does reduce like 2/3 of the state
you need to manage in your app. Only caveat is that it's somewhat arduous to
use unless you have a GraphQL backend, so you really do have to buy in to that
whole stack. That's sometimes a luxury not all products/teams are blessed
with.

------
rwbcxrz
> The concepts are clear to those with a Computer Science (CS) educational
> background, but since the large mass web developers come mostly outside of
> this arena it is a hindrance.

Seriously?

A CS degree is not necessary in order to understand functional programming,
and it's not like reducer functions are all that complicated.

~~~
cheez
The vast majority of developers absolutely cannot handle reducers. Give them a
pattern to follow and they'll follow, though.

~~~
poxrud
I think the difficulty is in making sure the state is not mutated. This is
unusual for most developers, especially those coming from an OOP background.

------
awinograd
The async rendering rendering stuff Dan is showing in his talk
([https://www.youtube.com/watch?v=_c7ajDXb4qw](https://www.youtube.com/watch?v=_c7ajDXb4qw))
looks great, but I disagree that this is a redux killer.

redux is useful for a lot more than just async fetching & loading. I think
these new features will just reduce the scope of what redux is used heavily
for.

~~~
city41
The video has been blocked. Anyone know of a mirror?

~~~
kanalas
[https://www.youtube.com/watch?v=v6iR3Zk4oDY](https://www.youtube.com/watch?v=v6iR3Zk4oDY)

~~~
city41
Thank you!

------
notmarkus
This might be one of the most poorly written articles I've ever seen on HN.

------
binocarlos
I use redux a lot and love the way you can reason about the state of the app
from a single object - which opens up all sorts of useful things like time-
travel etc.

However - after having plugged in a __lot __of reducers - the boilerplate code
required to do simple stuff becomes a real bore. I 've since compromised by
using a simple `key-value store` reducer that I can write new values to
without needing a new reducer with accompanying actions.

I'm sure this is not how it's supposed to be used but nobody ain't got no time
for making all that boilerplate just for a button :-)

Like I say - it's worth it though - it's amazing how large frontend apps "just
work" once you have the state in a single place and the UI rendering from it
and it alone.

~~~
cheez
I created a class compatible with Redux time travel and debugging tools that
works like this (in typescript):

    
    
        interface FooState {
          myNumber: number;
          myArray: number[]
        }
    
        class Foo extends DataModelImpl<FooState> implements 
        IDataModel<FooState> {...}
    

Then you use it like so:

    
    
        const foo:IDataModel<FooState> = new Foo()
        foo.updateState(state => state.myNumber = 10)
    

Anything that wants to be notified when myNumber changes:

    
    
        const callback = (num:number) => {...}
        const unsubscribe = foo.watch(state => state.myNumber,callback);
    
        ...
    
        unsubscribe()
    

I've bound this to React, Vue and other view libraries. It even works properly
with nested objects.

Drawback is that it uses Observers. I believe the next "killer state library"
will use a pattern like what I've described above.

~~~
darepublic
.watch? Reminds me of angularjs :)

~~~
cheez
Hah, that's right :)

------
girvo
One of my favourite parts of ReasonReact is that reducers are built in, out of
the box. The Future-Fetcher feature coming in React reminds me of that; I
recently built a React Native app that has 99.8% Flow type coverage, that’s
meaningful and has caught dozens of bugs as the team worked on it. Having nice
state management built into React will be lovely, and subsume a lot of the
type imports or duplication that using Redux, React and Flow together
currently requires.

------
martimoose
"However, fast forward to 2018 and React.js is the popular choice for React.js
development."

Huh?

~~~
maxaf
Brought to you by Erowid Blog Post v4.5!

------
kitd
In the future, JS libs will be popular for 15 minutes.

~~~
pjmlp
I will keep using VanilaJS, nothing else is worthwhile unless to pump up CVs.

~~~
monkeynotes
So for every project you implement solutions to common problems differently?

~~~
pjmlp
We use server side rendering with minimal JavaScript for dynamic behaviors.

ASP.NET, Spring and JEE work just fine.

~~~
monkeynotes
The answer to the complexity of JS and associated frameworks/libraries cannot
simply be "stop making JS apps".

Don't get me wrong, I agree server side rendering is a lot simpler and solves
many problems, but there are plenty of reasons to go with a full client-side
app and in those cases libraries and frameworks, while not essential, are
logical and sensible conclusions.

~~~
pjmlp
I rather prefer to eventually be able to use Web Components across all major
browsers.

~~~
joshribakoff
The spec constantly evolves. At some point, there will be web components "v2"
and coding "regular" web components will be outdated. As the spec evolves,
browsers will evolve at different paces & implement things differently. Such
is the reality of cross platform development. The only constant is change
itself. To deal with it we use tools like polyfills, libs, and frameworks.

~~~
pjmlp
That matters very little because our components are wrapped in ASP.NET,
Spring, JEE components.

For the user of use components the difference will be quite thin, if at all.

~~~
joshribakoff
Right, those things fall into the category of tools libs & frameworks. Like
Carl Sagan says if you want to make an apple pie from scratch you have to
first invent the universe. There's always going to be change and need to
support backwards compatibility, so polyfills libraries & frameworks likely
aren't going away anytime soon, even after web components are widely
supported.

------
davej
Dan's surname is Abramov, not Abramovich.

~~~
vadansky
Also

    
    
      However, fast forward to 2018 and React.js is the popular choice for React.js development.

~~~
Mchl
This whole article is full of misunderstandings and blatant mistakes. Hurried
writing on between conf sessions?

------
xbryanx
I think it'll also be interesting to see how Apollo continues to evolve in
this space as more people adopt GraphQL in their React apps. Apollo is getting
more and more state management features that can handle lots of what Redux is
doing:

[https://dev-blog.apollodata.com/the-future-of-state-manageme...](https://dev-
blog.apollodata.com/the-future-of-state-management-dd410864cae2)

~~~
chrisco255
Apollo uses Redux under the hood.

~~~
jlu
Not true for Apollo v2, it’s providing local state management via apollo-link-
state plugin which works pretty well, and once they got the rest support
working, it will be a very competitive alternative to redux.

------
mcintyre1994
This article is awful but Dan was tweeting about a big announcement in Iceland
last week so there probably is something awesome here!

------
matte_black
Good. Redux was never necessary for the vast majority of web apps, but too
many people promoted it as such.

------
enapupe
This video contains content from [Merlin] Beggars, who has blocked it on
copyright grounds.

------
icc97
Watching the video on Future Fetcher it feels like we're just inventing the
the web all over again.

Half the time is spent on novel new ways of adding in a loading spinner.
Perhaps it's just his demo, but I can sense Roy Fielding shedding a tear.

~~~
kanalas
I felt the same way. Felt like the ending of 2012 to me. Life begins again!

------
brian_herman
How does this compare to mobX?

