Ironically, it used to be much simpler. The community was very much around using Redux like you would event sourcing (even though thats not how it was talked about), and it was much into the FP/Elm-like patterns it provided. You could go on Discord and chat about a problem you had, and people were actively trying to solve it.
It didn't take long as Redux got popular for the discussion to turn into "how to avoid boilerplate", "how to make things more SOLID" (OOP principles in Redux, lol!), and "you should use setState most of the time".
That was the silent nail in the coffin. Very little progress was made in Redux patterns ever since that would not better be solved using other tools (MobX, Apollo, 16.3 context, whatever). Which is a shame: "Old school Redux" is amazing. There's a reason initially people flocked to it and said "OMG use it all the time for everything!". It's really that good. "Modern" Redux is a fragmented overcomplicated useless mess with a community that missed the point. Now get off my lawn, I guess.
I don't recall ever seeing comments about Redux and "SOLID". The commentary about "boilerplate" and use of `setState` has been in response to people's concerns. It's a shame that's where we've had to focus our time and attention in messaging.
Can you clarify what you mean in the last paragraph? What specific concerns are you thinking of?
I know you've talked in the past about the way your teams are using Redux. I'd love to see a couple posts that give some details on that.
You know I'm always happy to chat about ways we can improve the docs and help the community. _Please_ ping me sometime - I'd love to hear whatever suggestions you have. You know where to find me :)
Note that when I say the "community" here, I don't necessarly mean you or people close to the project, but I rather refer to what I've been seeing here internally, when talking to people at meetups, twitter, etc.
In the early days, the average Redux user was someone who had been burnt by Backbone or Angular 1.x state management, was excited about the solution Redux provided, was curious about Redux's FP characteristic or more rarely might even have been an FP zealot. There was a lot of chat around that area, how to handle specific problems from that angle.
As time went on and it became very popular, the "community" (I use the term loosely, as there's no single entity representing "the community") grew, and the typical Redux user was very much the same as the average JS dev. Usually a OO background or familiar with more classical languages and patterns. Just want to get shit done and doesn't care about the Redux pattern's unique characteristic. Uses Redux because everyone else is, not because they see value in the event sourcing-like decoupling.
A lot of things come from that. Like already mentioned, the focus came a lot more to "how to I reduce boilerplate", "waah I dont like passing props down", "code reuse!", "how do I make things look like my familiar OOP patterns".
That's all valuable and I don't want to downplay it (there's only so much nuance I can put in a stack overflow post), but a lot of this is available in other tools and other frameworks. MobX and state trees are pretty nice. I can just use that.
Redux itself has a few things others have not:
1- Popularity, but that's a completely artificial thing. Any other pattern could become popular. It does mean it has the most complete ecosystem, but we can replicate anything elsewhere if we need to.
2- FP-ish, Elm-esque, event sourcing-like characteristics. Nothing even remotely mainstream outside of other languages (Elm, PureScript, ReasonML) have this. But there's very little effort these days in tapping into it.
For example, the "connect all the things everywhere!" makes the predictable dataflow aspect of Redux a lot more fuzzy. In large apps we don't have much choice though: there are major perf issues if you don't connect deep enough. It's a problem that can be solved, but I've never seen it solved. Redux being used as a glorified context container to save on typing can be solved with better design patterns. There's very little research done in that area anymore, so it's here to stay. Side effects being handled by thunks/epics/sagas works fine, but we could do better. Back then there was a LOT of research and attempts done in that area (remember redux-loop? I miss redux-loop. The syntax sucked. Can't we do better, several years later in a world of generators, async/await and observables? I bet we can!).
The obsession in making Redux, a functional event sourcing like-thing into something palatable to the average developer is just trying to fit a square peg in a round hole. There's nothing unique about Redux to make it appeal to those use cases and sub community. What if we looked at Redux, and instead of only focusing on that, we pushed what makes it unique to it's limits?
After all, back when the first Redux demo and timetravel debugging was shown, the world revolved around OOP JavaScript. It pushed people out of their comfort zone a little.
I'd show you the code we write here, but with hundreds of devs, they learn from the same place everyone else do. As we've grown, all the patterns (and anti-patterns) you see everywhere are also present in our own code, and we fight these battles internally too.
This really isn't a form of discussion I feel is productive. To join force within a problem space and solve problems in that space, you need several people aligned on a common goal. The problem space and common goal I'm interested in isn't "How do we make Redux work for everyone", it's "given an assumption that certain FP patterns, event sourcing, global state and event logs are high value patterns, how do we solve real world problem with them". I'm not sure this is possible anyore without alienating tens of thousands of frontend developers, without starting something else from scratch.
Edit: phew I hit enter and didn't even realize how much I wrote.
So TL;DR. You and the rest of the team are doing a fine job, but as with all things that are popular, there are "sub communities", and its impossible to make everyone happy. My pie in the sky dream is for people that don't like Redux to use something else, and for Redux to focus on its strength instead of always trying to fight its (by design) weaknesses.
This comment deserves to be its own blogpost. This paragraph in particular is key:
> The obsession in making Redux, a functional event sourcing like-thing into something palatable to the average developer is just trying to fit a square peg in a round hole. There's nothing unique about Redux to make it appeal to those use cases and sub community. What if we looked at Redux, and instead of only focusing on that, we pushed what makes it unique to it's limits?
I've already spent more time in this thread than I really should have, and I'm also sorta slightly burnt-out after spending the last few weeks putting together my first Redux workshop. My immediate priorities for the near future are trying to consolidate the PRs and issues we have for updating React-Redux to work with React 16.3+, and pushing forward on the "redux-starter-kit" package I put together.
That said, yeah, I _hate_ that we've had to spend so much time "defending" Redux rather than figuring out niftier things to do with it. I've seen a lot of interesting experiments in the community, but haven't had time to really go off and investigate or play with them further. (I don't even have enough time for all the blog posts I want to write :( )
At a minimum, Redux has been hugely instrumental in changing the minimum bar for debuggability and state tracing, but yes, I'd love to figure out ways to push the envelope somehow.
> That said, yeah, I _hate_ that we've had to spend so much time "defending" Redux rather than figuring out niftier things to do with it
Yup, everything popular goes through that. I like the MMORPG analogy. New MMO comes out, is popular, shiny, everyone's into it. Then the WoW communities move to it and request...DEMAND that it be changed to match their expectations. Game devs try super hard to catter to the WoW communities and fail. WoW players all quit. Game developers then either give up, or focus on the core player base that actually liked the game as designed originally. At that point the game either thrives and becomes the best it's ever been (with a much smaller user base), or it dies.
Ember is one of those I think: I don't like it, but everyone who hates Ember stopped using it long ago, and it's serving people who like it quite well. It's not shiny or sexy, but for them, it works very well.
It didn't take long as Redux got popular for the discussion to turn into "how to avoid boilerplate", "how to make things more SOLID" (OOP principles in Redux, lol!), and "you should use setState most of the time".
That was the silent nail in the coffin. Very little progress was made in Redux patterns ever since that would not better be solved using other tools (MobX, Apollo, 16.3 context, whatever). Which is a shame: "Old school Redux" is amazing. There's a reason initially people flocked to it and said "OMG use it all the time for everything!". It's really that good. "Modern" Redux is a fragmented overcomplicated useless mess with a community that missed the point. Now get off my lawn, I guess.