FireFox Quantum on Windows 10 with a pretty badass CPU. Also slow in Opera. Also slow in Vivaldi.
And it crashed Chrome Canary.
For a web-tech post, this is pretty fucking bad.
I also tried scrolling a number of different ways - with autoscrolling, mousewheel, page up/down and arrow keys.
All of the machines I tried it on are 4-5 years old except for my iPhone which came out in 2017.
It works great.
Im not blaming redux for this, this is clearly a problem with how we implemented redux. But our team of 3 devs would be much much better off by having used Mobx.
I've seen better implementations of Redux and https://github.com/isubasinghe/advanced-redux-patterns is one of them (this is code by Nir Kaufman for his advanced redux patterns talk)
Out of curiosity, what issues have you been seeing with using thunks?
I'd specifically encourage you to check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:
You might also want to look at the new "Style Guide" page we've added to the docs, which lists our recommended patterns and practices for using Redux:
What changed everything for me was adding GraphQL and getting the majority of my API communication and data storage out of redux. Now, sagas and redux are further down the list of tools I reach for, complexity is way down across the board, and the sagas and reducers that’s remain are more narrowly scoped and easier to reason about and maintain.
I've used sagas in a couple apps that truly did have very complex async workflows, and they were great for that use case. But yeah, using sagas _just_ for something like data fetching is definitely overkill.
[0] https://redux.js.org/faq/actions#what-async-middleware-shoul...
[1] https://redux.js.org/style-guide/style-guide/#use-thunks-for...
Agreed. There's a simplicity to React / Redux that I absolutely adore. There's very little magic going on: things happen because you've explicitly told them to. Side-effects in Redux seem to throw this out the window.
API shapes change and evolve, and mapping raw API shapes to components (through Redux) became a major PITA, real fast.
reselect solved all of that; we transform almost all data to a “view layer friendly” format before passing it into the components, keeping them as dumb as possible. We also moved most “view business logic” to the selector level: The check might involve user permissions, subscription plan, etc, etc, but the component only receives ‘shouldThisThingBeDisplayed‘. API shape/changes very rarely impact the components.
This approach makes it much easier to test in our experience. Business logic is tested without any concern for the components themselves. Visuals are covered by Storybook and ChromaticQA.
But they all lead to things I would consider "hacky". Since it's all side effects, making sure two things that are "side effects" of the one action run in consistent order can be troublesome, since it's usually down to "well which one registered with the middleware first?"
And, if you ever need to actually simply `await` an action, you need to set up some middleware that will give you a promise that resolves / rejects when certain actions happen. Then you need to tie metadata to your actions if it stands that multiple of the action you're waiting to resolve happen.
Or, some people recommend creating a promise before dispatching, passing that promise reference around, checking for it in your sagas / observable.
All things I would consider super hacky.
I've been using my own middleware for years that simply lets you make `payload` a function, async function, or promise, and it's all incredibly more stable when things get complicated, and newcomers can grok whats going on in a second. You get `/start`, `/success`, `/error` actions baked in. And since it's promise-based, you can `await dispatch()` when you need to. If you need to get the state, or dispatch more actions, you can, right from the original action.
For times when you truly do want something to be a side effect (read: incredibly rarely because my actions have access to `dispatch` and `getState`), I use a very simple middleware like redux-saga but with standard async / await syntax.
I've been intrigued by people praising these side-effect workflows for some time, but after using redux-observable, I don't think I'll ever go near them again.
Apologies for the rant.
Jokes aside, everything has its place. You're still allowed to hate it though. For example, I hate Redux because everyone uses it for every React app and it's got boilerplate up the wazoo.
Just know that if you "hate" things, though, you won't learn as much in life, like I won't learn how to use time travel debugging. Almost anything that gets this popular has at least a few core ideas we should probably learn, or learn from.
Admittedly this works best on projects that don't require a massively complex interactive front-end, like news sites[0] and data reporting tools. But at some point you can just choose to start hydrating the interactive components in the browser without changing your back-end setup at all.
[0]: https://wildlyinaccurate.com/introducing-a-faster-bbc-news-f...
As people exited Rails, the cost of maintenance has gone up... since you have to pay a lot to get someone writing Rails now.
I'm using chrome on Android and it kills my browser every time.
Never mind the fact that we're plowing the depths of functional programming, complex data structures and asynchronous wizardry just to make sure that displaying a few bytes of text and flat-shaded borders isn't too slow.
I don't remember GUI programming being that hard in the years before this. At least for these rather simple results. Getting a full DTP platform out on a 20 mhz machine with 4 MB of RAM required some advanced pattern wizardry, but most web UI patterns aren't that complicated. They just aren't helped by the client-server nature and Javascript being Javascript, as much as you wrap it up in the Emperor's new C# clothes.
> Sites have become bigger, more interactive and more complex and this number is still gradually increasing in an upward trend year after year.
Yeah, but is it useful complexity? The whole frontend scene often reeks of "bullshit job" syndrome. To get results customers could live without in a framework not re ally suited for it, we're developing complex tools, even more complex tools to package and deploy them and then have more coaches, trainers, video walkthrough creators and premature optimization providers than ever before.
This comments section tho.
