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

101–109 of 109 posts

Re: Scheduling in React

#101

Post by bestest »

symboltoproc wrote: post #78
nkg wrote: post #67

As users, don't you get mad when you type "mustang" in an input and it displays "msutgna" because of some badly handled onChange event? We are overriding so much of the browser's default behavior that we need to reimplement its basic features.

I've never experienced that. Mind sharing an example?

That would happen when, for example, you're saving the value of the text input in redux, and the input is then updated with that value on change, although it's also updated by the user typing and the thread is blocked at the same time, thus we have a race condition.

That said — it only happens when one over-engineers stuff. Make sure to have a single source of truth, and that will be avoided.

Re: Scheduling in React

#102

Post by [deleted] »

bestest wrote: post #101
symboltoproc wrote: post #78

Earlier quoted context omitted.

I've never experienced that. Mind sharing an example?

That would happen when, for example, you're saving the value of the text input in redux, and the input is then updated with that value on change, although it's also updated by the user typing and the thread is blocked at the same time, thus we have a race condition. That said — it only happens when one over-engineers stuff. Make sure to have a single source of truth, and that will be avoided.

[deleted]

Re: Scheduling in React

#103

Post by philipp-spiess »

bestest wrote: post #101
symboltoproc wrote: post #78

Earlier quoted context omitted.

I've never experienced that. Mind sharing an example?

That would happen when, for example, you're saving the value of the text input in redux, and the input is then updated with that value on change, although it's also updated by the user typing and the thread is blocked at the same time, thus we have a race condition. That said — it only happens when one over-engineers stuff. Make sure to have a single source of truth, and that will be avoided.

The best approach is to always updated the input synchronously in React (in the same tick when the event is handled). If you do it in another tick, you will always have to handle race conditions. This is a problem for all input elements though, not specific to React or even the Web.

Re: Scheduling in React

#104

Post by nkg »

symboltoproc wrote: post #78
nkg wrote: post #67

As users, don't you get mad when you type "mustang" in an input and it displays "msutgna" because of some badly handled onChange event? We are overriding so much of the browser's default behavior that we need to reimplement its basic features.

I've never experienced that. Mind sharing an example?

The last time I experienced it I was using search bar on AliExpress.com's mobile website

Re: Scheduling in React

#105

Post by Tade0 »

philipp-spiess wrote: post #99
Tade0 wrote: post #95

Earlier quoted context omitted.

Debouncing just means the UI lock happens slightly less often. No, it means it happens only after the user stopped typing for a while - a very different experience. If you don't care, then why bother with auto-updating on keypress at all? Just wait for user to press enter. Doesn't cover all the cases and you have to update eventually - after the first debounced event goes through is a good moment.

The batching effect of a debounced input is very important. Running an update for every keystroke is expensive and you only want to run it with the latest input anyway. This is why Concurrent React will make batching the default behavior. Internally, React manages a list of updates. Whenever you trigger one, it will be added to the list but the next re-render will only start after the previous one has finished (this…

ELI5, what's the benefit here?

Because now I see mostly the cost of having pieces of the render function shoehorned between input events just so that they can be discarded, because once the render function finishes it's grossly outdated.

Re: Scheduling in React

#106

Post by philipp-spiess »

Tade0 wrote: post #105
philipp-spiess wrote: post #99

Earlier quoted context omitted.

The batching effect of a debounced input is very important. Running an update for every keystroke is expensive and you only want to run it with the latest input anyway. This is why Concurrent React will make batching the default behavior. Internally, React manages a list of updates. Whenever you trigger one, it will be added to the list but the next re-render will only start after the previous one has finished (this…

ELI5, what's the benefit here? Because now I see mostly the cost of having pieces of the render function shoehorned between input events just so that they can be discarded, because once the render function finishes it's grossly outdated.

Your users still want feedback _as they type_. The idea of this example though is that you want to see an update as soon as possible. If you use blur, you're also deferring the updates until the timeout is over for the first time - The timeout can only be approximated and will ultimately be more keystrokes behind as if we start rendering ASAP.

There is also the other problem with debounce that was pointed out earlier: The main thread _will be blocked_ when a long running tasks is executed, no matter _when_. You mentioned that the block would happen _after_ the user type in so it would be less noticeable but this is only an approximation. If you have animations on your website that use rAF, the block will still be very visible. Also if the user continues to type.

That said, I know that this is a contrived example and it might not be used as-such in a real world application. I also think it's not comparable to your auto-saving input example that would maybe be better off with using a debounce call. I'm sure that better examples for this use case will follow.

Edit: I can recommend Dan's talk at JSConf Iceland last year. He speaks about debounce as well: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...

Re: Scheduling in React

#107

Post by [deleted] »

BigJono wrote: post #90
bfrydl wrote: post #75

Earlier quoted context omitted.

That was a very defensive response. Look it's excellent for you that many people want to use your work and think it looks awesome. I am just not one of those people, for reasons developed over years of using Redux professionally. It seems like you think I am just missing something, and that's why I don't agree with you. You should really be more open to the idea that others might think very differently from you and t…

I've been down this path with acemarke before, about redux-thunk even. All of his commits on Redux are documentation changes, and he feels the need to spam every React thread on this site with comments that start with "I'm a Redux maintainer". In-fact if you google "Redux maintainer" this guy's posts are the first thing that shows up. Also, when React 16 came out with the new Context API, acemarke made a terrible blo…

[deleted]

Re: Scheduling in React

#108

Post by tracker1 »

bfrydl wrote: post #33
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…

I don't think redux-thunk is the simplest solution. There's really no need to add anything to redux to support asynchronous code. You can just pass the dispatch function around. For example: async function getArticle(id, dispatch) { try { const res = await fetch(`/articles/${id}`); const text = await res.text(); dispatch({ type: 'GET_ARTICLE_SUCCESS', id, text }); } catch (err) { dispatch({ type: 'GET_ARTICLE_FAILURE…

What you're describing isn't much different than the use of thunks generally...

    export const getArticle => event => async (dispatch, getState) => {
      const id = event.target.dataset.id;
      ...same as yours...
    }

    ...
The main difference is this works out of the box with connect, and can often be bound directly against a given event handler.

Re: Scheduling in React

#109

Post by [deleted] »

tracker1 wrote: post #108
bfrydl wrote: post #33

Earlier quoted context omitted.

I don't think redux-thunk is the simplest solution. There's really no need to add anything to redux to support asynchronous code. You can just pass the dispatch function around. For example: async function getArticle(id, dispatch) { try { const res = await fetch(`/articles/${id}`); const text = await res.text(); dispatch({ type: 'GET_ARTICLE_SUCCESS', id, text }); } catch (err) { dispatch({ type: 'GET_ARTICLE_FAILURE…

What you're describing isn't much different than the use of thunks generally... export const getArticle => event => async (dispatch, getState) => { const id = event.target.dataset.id; ...same as yours... } ... The main difference is this works out of the box with connect, and can often be bound directly against a given event handler.

[deleted]
Post reply on HN