121–130 of 133 posts
Earlier quoted context omitted.
Use mobx! It's 5% of the code you would have to write using redux and their gigantic box of tools.
Also check out mobx-state-tree...made by the same people and more suited towards large applications. I personally love mobx-state-tree (and mobx!). I really wish more would not jump straight for redux/etc without giving the powerful abstraction of observables via mobx a shot.
One underrated thing that I miss from using Redux is the "action trace". You can literally sit down with the stakeholders [1] and explain the exact things that caused a screen to render . And these things are not cryptic function calls with stack-traces, but simple and chronologically ordered sets of human readable "actions" (I like to think of them as events) like UserFetched -> PlanFetched ( ) -> FrozenUser. One ca…
Even better to combine this with sentry. So you can see all the actions that led to the error.
Earlier quoted context omitted.
In the vast majority of React apps you do not need this. I work on an app that has a total of about 400 separate Redux actions across half a dozen reducers and a couple of stores. There's a lot of things that cause side effects. Being about to see what actions fired with various props is immensely useful for debugging. redux-devtools and Reactotron are immensely useful. You're right that the majority of React apps do…
400 actions is actually not that much at all... I would even say, quite a small app.
Earlier quoted context omitted.
Right, and I'm saying that both `mapState` and `useSelector` perform the same behavior: allowing your component to subscribe to portions of the Redux store state, extract that, and update the component when that data changes. So, I don't understand what points your parent comment is trying to make, because the whole point of React-Redux _is_ to keep your components in sync with the data in the Redux store state.
We have run into several issues where a user clicks a button (which updates redux) and then quickly clicks on something else and the 2nd component has not been updated yet as it used the mapState prop (the update is being batched by redux and hasn't gone out yet to the listeners). Switched to using a shared model class instance - the value is changed immediately and anyone who needs to know the latest version can do…
I'm also not sure why you keep using the phrase "copies". The Redux store has the only actual copy of that data, and your `mapState/useSelector` functions typically return the actual references to that same data. The only copies made are if you make them yourself. Also, the value in the store _is_ already updated before any of the UI subscribers are notified.
Can you put together a sandbox that reproduces this problem and file an issue? I'm very curious what you're actually seeing.
Earlier quoted context omitted.
A lot of the pushback is coming from this: ‘ - Redux _has_ been over-used and put in apps where it didn't fit well, and I want people to only use it when it makes sense to do so’. ‘ There are developers working day in and day out in these Redux codebases so our feedback is coming from a real place. There’s a million articles that pushed Redux to the top and got it used in just about everything. Articles just like thi…
That's because: - I have no control over the millions of other tutorials that have been written. I can only control my own blog, and the actual Redux docs. - The question of "When does it make sense to use Redux?" has been answered numerous times already [0] [1] [2] - I wasn't trying to address the "when?" question in this article. I was trying to answer "is Redux still a viable choice, and how does it compare to oth…
CSS, SASS, redux, array.reduce, webpack are examples that come immediately to mind from the javascript world. There have been so many throughout the years
Earlier quoted context omitted.
No, I keep a very mercenary mentality when it comes to projects. I’m told what needs to be done and I do it and get paid for it. Early on in my career I cared too much, and it brought nothing but unnecessary stress. I will never sit down and watch a redux stack trace, it’s not my job and I got better things to do.
Have you written about this experience transition? I'm interested in reading stuff like this
I think a lot of developers start off the same way. Idealistic, starry eyed recruits eager to put their knowledge to use and make a product better than they found it.
But then you realize life’s too short to bother with things like Redux. We’re not building software to last thousands of years, there’s no future archaeologists who are going to spelunk through our ancient code and be in awe at the ingenuity of our primitive minds.
We’re lucky if we’re writing software that lasts a couple quarters. Especially when you’re building front end UI, you can expect whatever you do to be completely bulldozed by whatever trend or framework comes along.
So don’t care. It’s not your job, you’ll be paid regardless. If someone wants me to care about a project, they need to pay me extra. Because caring forces that project to take up space in my mind and takes attention and focus from other things I actually want to care about, such as getting my work done and meeting objectives. Early on I used to care so much it would actually interfere with my ability to get things done in a timely manner.
And when co-workers turn around and shit on you for slowing them down, and you see they don’t care either and still get the same pay and recognition, or maybe even more in some cases, you realize there’s no point. That’s not how this business works. Don’t be a hero.
By now I’m so experienced with React I don’t need some time travel debugging tool to tell me shit, even with very complex state. I never have. If I run through an error a few times and throw some console logs I can quickly find and solve the problem 99% of the time. A valuable skill.
Earlier quoted context omitted.
We have run into several issues where a user clicks a button (which updates redux) and then quickly clicks on something else and the 2nd component has not been updated yet as it used the mapState prop (the update is being batched by redux and hasn't gone out yet to the listeners). Switched to using a shared model class instance - the value is changed immediately and anyone who needs to know the latest version can do…
That sounds very surprising. Yes, React-Redux does batching and cascades updates through the UI layer, but that process should happen extremely quickly (far faster than the amount of time needed for someone to click on another button). I'm also not sure why you keep using the phrase "copies". The Redux store has the only actual copy of that data, and your `mapState/useSelector` functions typically return the actual r…
Most people have simple applications so redux works fine, but once you get complicated async work things just break down.
Earlier quoted context omitted.
That sounds very surprising. Yes, React-Redux does batching and cascades updates through the UI layer, but that process should happen extremely quickly (far faster than the amount of time needed for someone to click on another button). I'm also not sure why you keep using the phrase "copies". The Redux store has the only actual copy of that data, and your `mapState/useSelector` functions typically return the actual r…
Pretty easy - component that stores a redux computed value and a setTimeout that calls an action with the value. If the settimeout (or a websocket event, etc) fires before the batched update, you are out of sync. Most people have simple applications so redux works fine, but once you get complicated async work things just break down.
Earlier quoted context omitted.
Pretty easy - component that stores a redux computed value and a setTimeout that calls an action with the value. If the settimeout (or a websocket event, etc) fires before the batched update, you are out of sync. Most people have simple applications so redux works fine, but once you get complicated async work things just break down.
tbh that doesn't sound like a Redux-specific problem. That sounds like a general async / stale-references problem. If you've captured a value and try to use it later, then yeah, you're probably going not going to be using the latest version.
Earlier quoted context omitted.
That's because: - I have no control over the millions of other tutorials that have been written. I can only control my own blog, and the actual Redux docs. - The question of "When does it make sense to use Redux?" has been answered numerous times already [0] [1] [2] - I wasn't trying to address the "when?" question in this article. I was trying to answer "is Redux still a viable choice, and how does it compare to oth…
There is an odd dynamic that happens in tech: A framework or approach exists for a specific purpose; that framework is used badly or inappropriately by devs who don't fully understand it; those same devs spread the idea that said framework is bad/difficult/insecure and people who use it just don't know what they're doing; some of those devs happen to be "thought leaders" and use their platform to broadcast their misu…
So let’s see how this blame game works, because I have a hunch you want to aim it at people that think Redux is a bad choice.
You are suggesting that people that really don’t like Redux actually don’t know how to use it properly, misuse it, go down that rabbit hole and come out completely jaded by it. They then go on to provide their feedback, to which the obvious dismissive response is ‘well maybe you don’t know what your’re doing’. So the bad mouthing is actually occurring from the other side, no?
For the last few years, any job post you saw related to React, Redux was a prerequisite for probably over 90% of those posts. In other words, Redux was gospel, not the the feedback of naysayers. The mass broadcasting was happening by the framework adopters to the point said framework became ubiquitous.
Lastly, there’s very little feedback about Redux that has to do with people’s understanding of it. Almost the entirety of feedback is coming from usage of Redux and noticing by-products of using it (bloated code base, needless complexity - and this needless complexity criticism is ripe for being sniped by the framework advocates as a symptom of essentially incompetent developers who can’t see the elegance of Redux. The feedback is that it’s not elegant ).
The thought leaders are not the people providing negative feedback in this thread and elsewhere. The thought leaders, the gospel creators in this case are these Redux based articles/advocates that prolifically spread Redux throughout the React ecosystem to the point it became a standard dependency for every app.
In this case, this is a very real situation where it needs serious push back because it spread untethered and unexamined.
One thing I also want to point out, the same way the developer community has a responsibility to evaluate the proper usage of a technology, those who partake in pushing certain technology also have a responsibility of analyzing the impact of what they are evangelizing. One could argue it is irresponsible for influential subsets of the Javascript ecosystem to push a layer of complexity for apps that do not need to make the trade offs for a few features.