-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Answer to @faceyspacey #13
Comments
First and foremost: thanks a lot @faceyspacey! For real, thanks a lot for your kind words and for valuing my work. I really appreciate that. That being said, since you have given me so much advice, let me give you some of my own: do not jump to conclusions so quickly, especially if you don't know the full story.
Perhaps I already plan on creating my own repo despite this. Perhaps I will modulate that repo depending on the acceptance that this gets. Perhaps what drives me is not money and popularity. I don’t think that I’m martyring myself, what makes you say that?
I have been heavily using Redux since it was released. Like lots out there I use it in a very opinionated way, and like everyone else: I’m convinced that “my way” is the best way… I’m just self-aware enough to know that’s BS. The fact that through the years my opinionated way of using Redux has evolved a lot proves that. However, after all these years, I have noticed that there are some decisions/opinions that have barely changed (best tools for side-effect orchestration, the importance of declarative actions, etc), while there are others that I keep looking for ways to improve. One of the areas where I think that there is a lot of room for improvement is with the way that we derive data. I think that if we solve this one well, that will enable many other possible improvements (spoiler: the way that we connect redux with other libraries). What I know for sure is that I want to try my best not to fragment the Redux community. Also, why would I want to do that on my own if I can try to have the feedback of the core members of the Redux org?
Thanks! I actually think that I’m being bold and confident, I just don’t understand why being bold and confident has to translate into doing things on my own… In fact, I’m so bold and confident that without having ever worried about advertising my ideas or promoting myself (meaning that no one -except for the ppl that have worked with me- knows me), I have the courage to come here and propose a major version upgrade for a key library of the Redux ecosystem.
I’m motivated. However, I think that “my discoveries” don’t belong to me, whatever discoveries I make is thanks to what I have learned from others. So, I want to give back because I honestly think that it's a win/win.
I totally disagree with you on these things. I already told you that on Twitter. What the React team has done with hooks is beyond beautiful. It’s amazing, and from the POV of the library it’s awesome and it needed to be done. Same goes for Suspense, of course. I could write a long post about this idea of "hooks will kill Redux"... Instead, I will just say that the fact that now we have a better means to access React internals doesn’t mean that they have done that with the purpose to kill Redux. I really don’t understand what makes you think that. Although, to be completely honest with you, I’m zero attach to Redux itself. What I’m attached to is to what Redux allows me to do: a very nice way to separate state management and the side-effect orchestration, predictability, debugging tools, etc. I use Redux, because, in the way that I use it, it enables me to build nice Reactive solutions with it... But if you present me with another tool that enables me to do the same thing but in a better/easier way… I’ll take it, for sure! (Please don't ask me if I have tried Mobx... Yes, I have. And no, thank you!) Another reason why I’m not that attached to Redux itself is that -more often than not- I see Redux being used in ways that make me feel very sad… Like very, very, very sad. In fact, I will just go ahead and say it: I actually think that Redux-Thunk is the worse thing that has ever happened to the Redux ecosystem... There, I said it. Because IMO actions should be treated as events, not as instructions. I find it gross to dispatch some “future execution”. I think that makes the orchestration of side-effects supper messy, I think that puts developers into the mindset of dispatching “instructions” rather than dispatching events. I think that instructions-like-actions lead to worse reducers, etc, etc... You see, I have lots of opinions and Redux thankfully doesn’t. What I’m trying to say is that I don’t think that there is a “Redux path”.
I will admit that I’m pretty bad about promoting myself. I don’t even know how to get started with all that stuff. However, I don’t think that it is anyone else’s fault but mine the fact that my article on medium has so few likes… I did try to promote it a bit when I published it, but I didn’t even know how to do that properly, so I think that is my fault. However, I find it a bit ironic that you say this, because I think that the reason why you saw the post is that Mark Erikson has talked about it, right? I mean, I will admit that I should start promoting some of my ideas. I have done a few brown-bags and L&L, so I guess that I should try to start going beyond that… It’s just that it’s very time-consuming. Also, I know that there are a few ppl that don't play very nice in this community, but I want to think that most ppl are not like that.
It’s possible :)
I don’t even know how to answer this… It would take me to long. Sorry. Thanks for the advice, I gues... I will just say that if I haven’t finished figuring out the “basis” I don’t feel comfortable building “fuller tools”, yet, but who knows, maybe one day…
Thanks a lot for these kind words. I will keep trying to improve this ecosystem. |
One must do this for money or one must continue to work for clients or employers. If you don't have a strategy to make money doing this, you can't support and evolve your tools for long. I'm gonna send you something privately that will eliminate confusion. We could use your help. ps. it's not about the strict intent behind the new React features, it's about what the new capabilities amount to. As I wrote on Twitter, Redux isn't modular, and we need to fix that for Redux to continue. It's a worthy cause because there's a lot of latent capabilities in Redux we have yet to tap into. The single store approach has many un-tapped into benefits. |
I disagree with you on this one. I could tell you the same thing that I told Ryan Florence a couple of days ago. The kind of Redux that I write is actually very modular. Perhaps we need better tools to make that modularity easier? But I think that Redux -used correctly- can be very modular... To the point where you can actually do code-splitting in a fairly painless manner. I have done it, without using any of the helper-libraries that exist out there and it was not that difficult. The rootReducer is a pure function that gets composed using many other reducers and reducer-enhancers... Therefore the rootReducer can be modular. Also, Redux provides an API for replacing it when necessary. Maybe we are talking about different things here, sorry. Perhaps I'm not following you. If you could please show me a real-life example, with code, showing me what you mean by "redux isn't modular", I would really appreciate that. PS: I'm about to look at what you sent me. I just need to write a comment into the v5 proposal and I will look at it carefully. Thanks a lot! |
"Modular" Redux is a very broad thing - from lazy loaded reducers to a fractal state. I am quite interested to hear more about your approach/structure. |
Just creating a fake issue to answer this comment.
The text was updated successfully, but these errors were encountered: