4 ms·

>Redux is too simplistic, though +1. Redux is a great library, but I think its a little hard to grasp at first, and it doesn't yet provide a proper framework f

>Redux is too simplistic, though +1. Redux is a great library, but I think its a little hard to grasp at first, and it doesn't yet provide a proper framework for solving problems in a clear manner. It wasn't until a year + of using Redux and reading quite a bit code until I developed a mental framework for how to approach certain components in Redux (and whether to use Redux at all, vs. setState). Your "chart grid" example is something that I went through 3 iterations of until developing the "right" higher order component (which if you squint, could be confused for meta programming) for our use case. As a developer what you want is the right abstraction that prevents your "dataset ID" from leaking everywhere (ideally only your HoC should care about your "dataset ID", much the "redux-form" API you really don't need to interact with the "form" name once you've defined it). Once you have that, then you hopefully you have a reusable API that can scale or at least small enough to live in one developer's head without them having to wrestle with the entire application. I'm not sure how you fix it. Most of the patterns I discovered already exist under many different Medium articles.

shados 9y ago
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.
- acemarke 9y ago
  Hiya, Shados. Long time no chat :) 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 :)
  - shados 9y ago
    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. I'd be more than happy to chat more, but to me, that was always a battle that was lost years ago, when discussions devolved into "ivory tower vs pragmatism" (remember http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho... ?) 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.

shados 9y ago

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.

acemarke 9y ago
Hiya, Shados. Long time no chat :) 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 :)
- shados 9y ago
  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. I'd be more than happy to chat more, but to me, that was always a battle that was lost years ago, when discussions devolved into "ivory tower vs pragmatism" (remember http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho... ?) 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.