Scheduling in React
philippspiess.com
Scheduling in React
1–10 of 109 posts
Re: Scheduling in React
#2There's definitely some very cool work here... I do think that it's important to remember that the simplest solution is usually the best one to start with. I typically start with redux and redux-thunks with react apps, mostly because I will nearly always hit a point in complexity where it is worth separating state management from the main UI, and thunks is the simplest extension to support async interactions to a server.
From there, debounce or concurrent interactions are probably an easier stopgap first. At least until these APIs are distilled a bit, and abstractions make them easier to work with.
This can all be summed up with: YAGNI and "Don't prematurely optimize" I've only had a handful of cases where I had to make things more difficult because of behavioral issues in browser applications.
Re: Scheduling in React
#3There's definitely some very cool work here... I do think that it's important to remember that the simplest solution is usually the best one to start with. I typically start with redux and redux-thunks with react apps, mostly because I will nearly always hit a point in complexity where it is worth separating state management from the main UI, and thunks is the simplest extension to support async interactions to a ser…
>> simplest solution is usually the best one to start with. I typically start with redux
?? Redux is definitely not the simplest solution :) I’d argue that starting with local state (which is what hooks seems to be headed towards), then profiling, testing, and adding small amounts of debouncing code where appropriate is more aligned with your sentiment of “don’t prematurely optimize” vs starting with redux.
Re: Scheduling in React
#4AFAIK concurrent React breaks a lot of the currently existing ecosystem. For example, I think right now the current versions of redux and MobX don’t work with it. Granted, concurrent mode is not even close to out yet, but I’m curious what the migration path looks like.
Re: Scheduling in React
#5There's definitely some very cool work here... I do think that it's important to remember that the simplest solution is usually the best one to start with. I typically start with redux and redux-thunks with react apps, mostly because I will nearly always hit a point in complexity where it is worth separating state management from the main UI, and thunks is the simplest extension to support async interactions to a ser…
>> simplest solution is usually the best one to start with. I typically start with redux ?? Redux is definitely not the simplest solution :) I’d argue that starting with local state (which is what hooks seems to be headed towards), then profiling, testing, and adding small amounts of debouncing code where appropriate is more aligned with your sentiment of “don’t prematurely optimize” vs starting with redux.
Then you end up with data fetches being tied to the rendering lifecycle in a way that makes modifying the mechanism painful
Re: Scheduling in React
#6Impressive, but I don't think there's much of a use case for this.
Sure that last example ran at close to 60fps, according to the meter, but did it really?
I mean, as a user I experienced no performance gains, because I was focused on that lower part of the UI and I think most users would as well.
Re: Scheduling in React
#7There's definitely some very cool work here... I do think that it's important to remember that the simplest solution is usually the best one to start with. I typically start with redux and redux-thunks with react apps, mostly because I will nearly always hit a point in complexity where it is worth separating state management from the main UI, and thunks is the simplest extension to support async interactions to a ser…
>> simplest solution is usually the best one to start with. I typically start with redux ?? Redux is definitely not the simplest solution :) I’d argue that starting with local state (which is what hooks seems to be headed towards), then profiling, testing, and adding small amounts of debouncing code where appropriate is more aligned with your sentiment of “don’t prematurely optimize” vs starting with redux.
You'll eventually need data in the global state in anything but a toy app.
Re: Scheduling in React
#8Impressive, but I don't think there's much of a use case for this. Sure that last example ran at close to 60fps, according to the meter, but did it really? I mean, as a user I experienced no performance gains, because I was focused on that lower part of the UI and I think most users would as well.
I found the second example to be way less janky. I want to be able to see what I type as I type it (e.g. for spelling mistakes).
Taking a second to correlate that with results I am willing to accept, but if an app is janky with basic interactions I am leaving.
Re: Scheduling in React
#9Earlier quoted context omitted.
>> simplest solution is usually the best one to start with. I typically start with redux ?? Redux is definitely not the simplest solution :) I’d argue that starting with local state (which is what hooks seems to be headed towards), then profiling, testing, and adding small amounts of debouncing code where appropriate is more aligned with your sentiment of “don’t prematurely optimize” vs starting with redux.
You'll eventually need data in the global state in anything but a toy app.
Putting everything in global state gets really hard to maintain above a medium-sized app.
Re: Scheduling in React
#10There's definitely some very cool work here... I do think that it's important to remember that the simplest solution is usually the best one to start with. I typically start with redux and redux-thunks with react apps, mostly because I will nearly always hit a point in complexity where it is worth separating state management from the main UI, and thunks is the simplest extension to support async interactions to a ser…
>> simplest solution is usually the best one to start with. I typically start with redux ?? Redux is definitely not the simplest solution :) I’d argue that starting with local state (which is what hooks seems to be headed towards), then profiling, testing, and adding small amounts of debouncing code where appropriate is more aligned with your sentiment of “don’t prematurely optimize” vs starting with redux.
Hi, I'm a Redux maintainer. A few thoughts.
There's a couple ways to approach building out an app:
- Start as small and as simple as possible, and add more pieces down the road once you need them
- Determine up-front if you think you'll need various pieces, and get that infrastructure in place at the start .
Either of those is a reasonable way to tackle things.
As a related note, I'll put in a pitch for our new Redux Starter Kit 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 without writing any action creators or action types by hand: