21–30 of 47 posts
@inject
and you can call/set @observables easily.
It's much easier to onboard people. Redux is just a spaghetti mess of files upon files, trying to find the actual implementation of something. A mess.
---
I also looked into Apollo and it's obscenely good! Terrific dev UX. I'm heavily researching it currently.
Using redux v4 with react-redux v5 for a large and complicated project. Was looking into react-redux v6 but it looks like there may be a significant performance hit ( https://github.com/reduxjs/react-redux/issues/1164 ) so will hold off on it now. react-apollo is very interesting to me, but my understanding is that we'd need a graphql compatible backend, which we don't have
This statement reminds me of my enterprise Java days. It consisted entirely of just gluing together an endless conglomeration of shit with Spring sitting at the center.
There was never actually any software development, just configuring an ever evolving mess of frameworks to talk to each other. When you offload all your engineering to frameworks, most of the bugs end up being due to some poorly understood interaction between components.
Kinda feels like the JavaScript world is starting to invent J2EE...
Been using MobX for about three years and I think it is wonderful. Incredibly easy to use (mark your variable as observable, modify it like you would any normal variable, and any components which use those variables in their rendering and are marked as observers automatically update), very performant out of the box (only components affected by a change re-render so no shouldComponentUpdate needed) and some excellent…
Using redux v4 with react-redux v5 for a large and complicated project. Was looking into react-redux v6 but it looks like there may be a significant performance hit ( https://github.com/reduxjs/react-redux/issues/1164 ) so will hold off on it now. react-apollo is very interesting to me, but my understanding is that we'd need a graphql compatible backend, which we don't have
I wouldn't call it a _significant_ performance hit. There's a measurable difference in our artificial stress tests benchmarks, and some users have reported slowdowns in specific scenarios (especially when large forms are connected to Redux).
I recently posted a roadmap issue with our plans for addressing the perf issues, and moving towards the ability to ship a hooks-based API for React-Redux:
https://github.com/reduxjs/react-redux/issues/1177
I've specifically spent the last week experimenting with reworking the internals of `connect` to come up with an alternative implementation that relies on direct store subscriptions again, and as of a couple days ago, I seem to have come up with something that is actually _faster_ than both v6 _and_ v5 in our benchmarks:
https://github.com/reduxjs/react-redux/issues/1177#issuecomm...
Still needs more investigating and testing, but this approach looks very promising.
Using redux v4 with react-redux v5 for a large and complicated project. Was looking into react-redux v6 but it looks like there may be a significant performance hit ( https://github.com/reduxjs/react-redux/issues/1164 ) so will hold off on it now. react-apollo is very interesting to me, but my understanding is that we'd need a graphql compatible backend, which we don't have
> Using redux v4 with react-redux v5 for a large and complicated project. Was looking into react-redux v6 but... This statement reminds me of my enterprise Java days. It consisted entirely of just gluing together an endless conglomeration of shit with Spring sitting at the center. There was never actually any software development, just configuring an ever evolving mess of frameworks to talk to each other. When you of…
The Redux core is tiny and very stable. There were a couple technically "breaking" changes within the first couple months after it hit 1.0 in July 2015, and it stayed on 3.x until the middle of last year. The bump to 4.x was primarily due to updated TypeScript typings.
React-Redux has also been very stable, especially in terms of public API. We've reworked the internals a couple times to address various aspects of interacting with React, but the public API has been basically unchanged since the start of 2016.
I wrote a post on "The History and Implementation of React-Redux" that explains what React-Redux does, how it's evolved over time, and why the various changes were made:
https://blog.isquaredsoftware.com/2018/11/react-redux-histor...
Long-term, I want this to be the standard way that most people use Redux.
Been using MobX for about three years and I think it is wonderful. Incredibly easy to use (mark your variable as observable, modify it like you would any normal variable, and any components which use those variables in their rendering and are marked as observers automatically update), very performant out of the box (only components affected by a change re-render so no shouldComponentUpdate needed) and some excellent…
If you have a team that writes spaghetti code, or never has time to refactor, or doesn't have effective communication then things will be worse with Redux, because it makes the code much harder to follow (good luck stepping through things in a debugger to see how they work, for example).
This is mostly intended as a criticism of people/teams who think adopting Redux will solve problems with the messiness of their code. But I also think Redux is overly complicated and too abstract for 95% of projects. And don't get me started on Sagas...
I would recommend setState as far as you can push it, then choosing something conceptually simple like MobX (Or MobX State Tree), React Easy State, or whatever the one from Formidable Labs is. Using Redux correctly is not as simple as it seems on the surface, and it requires real thought and real understanding o t