Live data from Hacker News

Scheduling in React

philippspiess.com

11–20 of 109 posts

Re: Scheduling in React

#11
post #7

Earlier quoted context omitted.

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.

But... It's not a choice of one or the other, both global and local must be used appropriately.

Also the shape of your global state plays a big role in its maintainability and redux provides good tools and documentation to achieve that.

Re: Scheduling in React

#12
post #7
post #3

Earlier 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.

I generally agree but actually the new hooks allow you to pass certain values down to all children automatically, so I think just hoisting this logic to the highest point that makes sense has this covered to some degree.

Re: Scheduling in React

#13
I understand the need but this adds serious complexity and wouldn't recommend that this becomes the standard for UX in React. A user is often ok with a delay and it may not worth the tech debt. That said, a very well written article.

Re: Scheduling in React

#14
I think this is a great point made. I wonder if it makes sense to build into the core of react to have render method execute on priority levels configured for the components themselves. I agree that this adds a good deal of complexity otherwise for quicker projects.

Re: Scheduling in React

#15
post #3
post #2

There'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.

Man, why does every single thread about anything remotely related to react devolve into a flamewar about redux? I wish we could all move on from this tired old debate. Everyone is free to use or not to use redux. If your team uses redux and you hate it, that is not redux's fault.

Re: Scheduling in React

#16
post #7

Earlier quoted context omitted.

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.

You can still slice state into separate reducers and action creators. I use a feature oriented directory structure, so that a given feature may have components/controls, action creators and/or reducers, but not necessarily all of the above.

It sounds a little convoluted, but in practice it's made it easier for developers coming in to discover/predict where things are.

Re: Scheduling in React

#17
post #7

Earlier quoted context omitted.

You'll eventually need data in the global state in anything but a toy app.

I generally agree but actually the new hooks allow you to pass certain values down to all children automatically, so I think just hoisting this logic to the highest point that makes sense has this covered to some degree.

I would argue that you should indeed hoist your data to the highest point, but definitely not your logic. Otherwise you end up with a big mega-component at the top level that contains fragments of business logic for many unrelated features, and coupling your business logic to your view component hierarchy is not a good idea. Changing your page layout should never break your application. I don't advocate any particular solution to this problem but I do believe that you need some kind of architecture that allows you to decouple your UI code from your application code.

Re: Scheduling in React

#18
post #3
post #2

There'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.

More often than not you should have a general feel for how complex your app will grow in the medium / near term. If it's going to get beyond "toy" you might as well take the plunge with Redux up front. Starting your design with it is much easier than trying to shoe-horn it in later, even if the cost at the outset feels heavy.

If you're fairly confident your app won't get too over the top, then by all means go the easy route!

Re: Scheduling in React

#19
post #3
post #2

There'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.

No, it really isn't... but it's a level of complexity that once inherited doesn't get much more complicated as you add more features. It's also imho one of the best options for separating state management.

In general, prop drilling is simpler to start with, but quickly turns into spaghetti... you can use the new context options, but they aren't much easier than using Redux at that point, and can become much more complicated.

Re: Scheduling in React

#20
post #7

Earlier quoted context omitted.

You'll eventually need data in the global state in anything but a toy app.

I generally agree but actually the new hooks allow you to pass certain values down to all children automatically, so I think just hoisting this logic to the highest point that makes sense has this covered to some degree.

I think you're talking about context, which isn't specific to hooks. Hooks give functional components features that only existed for classes.

First of all, context is slow, at least currently. Secondly, it's just a vehicle for delivering deep updates. It should be used when local state is not enough, but it's only an intermediate step before needing redux-like state Management and all the convenience it provides.

Post reply on HN