Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scheduling in React

philippspiess.com

Post reply on HN
Print view View original

21–30 of 109 posts

Re: Scheduling in React

#21

Post by acemarke »

tracker1 wrote: post #16
lilactown wrote: post #9

Earlier quoted context omitted.

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.

Yep. I've settled on a "feature folder" approach myself. When we finally get around to revamping the Redux docs content, I plan on having a "Style Guide" page similar to the one in the Vue docs, which would offer opinionated suggestions with an indication of how important each one is. One of the items I definitely plan to include in there is a suggestion to use feature folders. I also want to reorganize our example apps based on that structure as well.

See this issue for details on the docs rewrite:

https://github.com/reduxjs/redux/issues/3313

Re: Scheduling in React

#22

Post by Klathmon »

m0meni wrote: post #4

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

I don't know the answer (or if there is a fully formed answer at this point), but I have heard the React team talk about this a bit.

Facebook internally has a MASSIVE number of components, and apparently a lot of them are using older APIs and older paradigms. Because React is ultimately by and for Facebook, they simply can't afford to make lare breaking changes, it's just not a realistic option. Everything they do has to have a good mostly-automatable path forward.

I don't know for sure how they will handle it, but I have a feeling it will be using the StrictMode stuff that they introduced a few versions ago. I'd wager they will have a way to enable concurrent react for a Component and the tree of children nodes, and will stick to the current implementation for everything that isn't compatible. This will let you enable the new features in only parts of your app that need it, or slowly migrate over to it and opt-in over time. And I believe I read somewhere that if a component runs happily in StrictMode that it's already concurrent-react ready (but please don't take that as fact!).

Re: Scheduling in React

#23

Post by sktrdie »

I feel that this low-level performance stuff should exist in browser-land and not in framework-land. Kudos to React for finding a good implementation though

Re: Scheduling in React

#24

Post by manigandham »

tracker1 wrote: 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…

You can use Mobx and get around all the manual effort of Redux.

Re: Scheduling in React

#25

Post by exogen »

korm wrote: post #20
sammorrowdrums wrote: post #12

Earlier quoted context omitted.

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.

There's also a big piece that people who see useContext/useReducer as a replacement for Redux usually miss: server side rendering.

The Redux store lives outside of the React component tree and has a getState() method to capture the state of the store and deliver in the SSR payload. With useContext/useReducer, the state lives in the lifecycle of a top-level component. Unless you build something equivalent to Redux's store anyway, you're not going to be able to easily get a snapshot of its state out of that component. Unless, I suppose, that component itself knows to put its own payload in a tag in its render() on the server only (in which case you'd still get a hydration mismatch).

Re: Scheduling in React

#27

Post by acemarke »

Klathmon wrote: post #22
m0meni wrote: post #4

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

I don't know the answer (or if there is a fully formed answer at this point), but I have heard the React team talk about this a bit. Facebook internally has a MASSIVE number of components, and apparently a lot of them are using older APIs and older paradigms. Because React is ultimately by and for Facebook, they simply can't afford to make lare breaking changes, it's just not a realistic option. Everything they do ha…

Yeah, ConcurrentMode is going to be entirely opt-in, per subtree, as a component: ``. And yes, that's the point of ``: a form of runtime linting for known patterns that will cause problems in CM.

Re: Scheduling in React

#28

Post by mpweiher »

sktrdie wrote: post #23

I feel that this low-level performance stuff should exist in browser-land and not in framework-land. Kudos to React for finding a good implementation though

Or maybe not even in the browser but in the OS?

It is interesting how we build a new layer on top, and then notice that we need to reproduce all the functionality of the lower levels.

Maybe Open Implementation wasn't such a bad idea?

Re: Scheduling in React

#29

Post by pmdarrow »

sktrdie wrote: post #23

I feel that this low-level performance stuff should exist in browser-land and not in framework-land. Kudos to React for finding a good implementation though

The Chrome dev team is working to create a scheduling API in the browser: https://github.com/spanicker/main-thread-scheduling

Re: Scheduling in React

#30

Post by ergothus »

tracker1 wrote: post #16
lilactown wrote: post #9

Earlier quoted context omitted.

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.

I too prefer feature folders. I wish it was the example most used...as it is we have a convention that has no reason other than "this how I first saw it done".
Post reply on HN