Answer to @faceyspacey
josepot opened this issue · comments
Just creating a fake issue to answer this comment.
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.
If you are the most motivated in this space as of 2019, build it under your name and collect credit which will help you get jobs and clients, which in turn will reinforce your motivation to maintain and evolve it. Having successful repos under your name can make you hundreds of thousands of dollars and change your life. My recommendation is to not martyr yourself.
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?
The sentiment is nice, but isn’t necessary beyond getting the community to look at your solution. Fork React-Redux if you have to (which I see you have). Fork Redux itself. Preserving the old for so long has just resulted in decay. Redux is in great need of a makeover; it’s inevitable. There’s so many places we never took these tools—mainly because people get the wrong idea that there’s nothing left to do and it’s “done.”
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?
What you are working on is a key piece. Be bold and confident in what you intuit to be the way forward.
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.
If, on the other hand, you’re not motivated to carry the flag for very long and just wanna pass off your discoveries, that’s another story. But don’t be afraid to replace the status quo—that’s what software is about and what is currently lacking in the stagnant React landscape.
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.
With hooks it might not be clear, but the pace of innovation has greatly slowed in the space compared to a few years ago...And innovation trumps fatigue, to say the least.
React, with hooks and suspense, is making an attempt to replace Redux. There will need to be a Redux renaissance for it to survive. And I think it should survive because there are things we can’t do with hooks/suspense, and more importantly latent capabilities that have yet to evolve in the Redux path.
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”.
The core of what your doing here revolves around promotion. From experience, don’t expect the powers that be to give a shit or help you. That’s clear by how few likes you got on your amazing launch article on medium from a month ago. You deserve a lot more. That’s a sign of how shitty the React game is and how little influencers ultimately know. Don’t depend on them. You gotta do your own promotion, and an endless amount of it.
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.
The developers that know the most work on real projects, often ones they own or are technical leads in, and have little time for the misleading echo chamber of react tweets and articles.
It’s possible :)
Next suggestion: build fuller tools worthy of your time promoting it. Your fork of React-Redux is an example of this, whereas your fork of reselect isn’t. In other words, build a tool big enough that it’s a primary pillar to how people build their apps, rather than a hidden implementation detail. Something with a significant api surface and many ways to use it will bring you tons of paying clients in need of your wisdom.
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…
Your work is actually pretty far along the spectrum toward being a contender people need to take seriously. You are doing real innovation. Unfortunately obvious innovation that needed to be done long ago. But thankfully you are finally doing it...I make those last comments just to indicate that the ecosystem is totally (and always) up for grabs for those that have the time and vision to enhance it.
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.
Redux isn't modular, and we need to fix that for Redux to continue
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.