Earlier quoted context omitted.
We use server side rendering with minimal JavaScript for dynamic behaviors. ASP.NET, Spring and JEE work just fine.
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.
RIP Redux: Dan Abramovich Announces Future-Fetcher
31–40 of 49 posts
Re: RIP Redux: Dan Abramovich Announces Future-Fetcher
#32I 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…
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) => {...}
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.
Re: RIP Redux: Dan Abramovich Announces Future-Fetcher
#33I 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...
Re: RIP Redux: Dan Abramovich Announces Future-Fetcher
#34> 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.
Re: RIP Redux: Dan Abramovich Announces Future-Fetcher
#35Re: RIP Redux: Dan Abramovich Announces Future-Fetcher
#36Future 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…
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.
Re: RIP Redux: Dan Abramovich Announces Future-Fetcher
#37Earlier quoted context omitted.
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.
I rather prefer to eventually be able to use Web Components across all major browsers.
Re: RIP Redux: Dan Abramovich Announces Future-Fetcher
#38The 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.
Re: RIP Redux: Dan Abramovich Announces Future-Fetcher
#39Re: RIP Redux: Dan Abramovich Announces Future-Fetcher
#40Earlier quoted context omitted.
I rather prefer to eventually be able to use Web Components across all major browsers.
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.
For the user of use components the difference will be quite thin, if at all.