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

RIP Redux: Dan Abramovich Announces Future-Fetcher

react-etc.net

Post reply on HN
Print view View original

41–49 of 49 posts

Re: RIP Redux: Dan Abramovich Announces Future-Fetcher

#41

Post by poxrud »

cheez wrote: post #34
rwbcxrz wrote: post #19

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

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

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.

Re: RIP Redux: Dan Abramovich Announces Future-Fetcher

#42

Post by chrisco255 »

joshribakoff wrote: post #36
chrisco255 wrote: post #16

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

https://dev-blog.apollodata.com/the-future-of-state-manageme... 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.

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.

Re: RIP Redux: Dan Abramovich Announces Future-Fetcher

#43

Post by mpjme »

cheez wrote: post #34
rwbcxrz wrote: post #19

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

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

It seems like you have some stats I don't have access to. Care to share? I feel it implausible that given reduce is a functionality built into JavaScript, very useful, and that it's the worlds most common programming language saying the vast majority seems like a stretch.

Re: RIP Redux: Dan Abramovich Announces Future-Fetcher

#44

Post by kanalas »

city41 wrote: post #38
awinograd wrote: post #13

The async rendering rendering stuff Dan is showing in his talk ( 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.

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

https://www.youtube.com/watch?v=v6iR3Zk4oDY

Re: RIP Redux: Dan Abramovich Announces Future-Fetcher

#45

Post by kanalas »

icc97 wrote: post #21

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.

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

Re: RIP Redux: Dan Abramovich Announces Future-Fetcher

#46

Post by darepublic »

cheez wrote: post #32
binocarlos wrote: post #25

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…

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 implements IDataModel {...} Then you use it like so: const foo:IDataModel = new Foo() foo.updateState(state => state.myNumber = 10) Anything that wants to be notified when myNumber changes: const callback = (num:number)…

.watch? Reminds me of angularjs :)

Re: RIP Redux: Dan Abramovich Announces Future-Fetcher

#48

Post by joshribakoff »

pjmlp wrote: post #40
joshribakoff wrote: post #37

Earlier quoted context omitted.

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.

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.

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.

Re: RIP Redux: Dan Abramovich Announces Future-Fetcher

#49

Post by cheez »

darepublic wrote: post #46
cheez wrote: post #32

Earlier quoted context omitted.

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 implements IDataModel {...} Then you use it like so: const foo:IDataModel = new Foo() foo.updateState(state => state.myNumber = 10) Anything that wants to be notified when myNumber changes: const callback = (num:number)…

.watch? Reminds me of angularjs :)

Hah, that's right :)
Post reply on HN