This seems pretty nice! Personally, for most cases, I would just fix the actual problem instead (long-running tasks) by either moving them to a Worker, batching the work or using some LOD algorithm to only run to work for the needed granularity. This would improve the UX a lot and is not something that you have to do to often anyway.
Scheduling in React
31–40 of 109 posts
Re: Scheduling in React
#32There'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…
IME, Mobx is much simpler than Redux. /$.02
Re: Scheduling in React
#33There'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', id, err });
}
}
Re: Scheduling in React
#34Earlier 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.
The new hooks are a great way to use redux, not a reason not to use it. A “useStore” hook is much easier to understand than react-redux's connect.
Re: Scheduling in React
#35This seems pretty nice! Personally, for most cases, I would just fix the actual problem instead (long-running tasks) by either moving them to a Worker, batching the work or using some LOD algorithm to only run to work for the needed granularity. This would improve the UX a lot and is not something that you have to do to often anyway.
The worker approach doesn't work if you need to update lots of Dom nodes. The example being a highlighter for a search term.
While LOD would work (e.g., only update on screen names), the work featured to set that up is non trivial
Re: Scheduling in React
#36[deleted]
Re: Scheduling in React
#37There'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…
Yes, it's true you can do that. However, it's not what we recommend.
I specifically addressed the reasons why we recommend using middleware in the "Side Effects" section of my "Redux Fundamentals" workshop slides [0] [1].
The Redux FAQ entry on "Why do we need things like middleware for async behavior?" [2] also addresses this. In particular, I recommend reading Dan Abramov's answers on Stack Overflow on this top [3] [4]
As always, it's up to you how you choose to write your code, but there's plenty of good reasons why middleware is our recommended approach.
[0] https://blog.isquaredsoftware.com/2018/06/redux-fundamentals...
[1] https://blog.isquaredsoftware.com/presentations/workshops/re...
[2] https://redux.js.org/faq/actions#how-can-i-represent-side-ef...
[3] http://stackoverflow.com/questions/34570758/why-do-we-need-m...
[4] http://stackoverflow.com/questions/35411423/how-to-dispatch-...
Re: Scheduling in React
#38We used this technique in the IE6 days (with settimeout nonetheless). We had a very big list that was being filtered as the user typed, and we would perform 10 dom operations (they were all creating and appending elements to the dom), then timeout for 15ms, then 10 more operations, etc. If the user changed the text, we would clear the most recent timeout which would stop the chain, it was very clean actually. I suppose with requestAnimationFrame it's a bit nastier as you 'd need like a __dirtyRequestStop boolean check to break the scheduling, but probably much more elegant performance wise.
The concept behind it, is that you give "air to the UI thread to breath". Basically instead of locking it for 100ms you lock it for less at the time, which is perceivable as just a delay, rather that the window completely freezing. Users would see the list progressively be created sometimes which was cool too, gave it a feeling of "this is doing some heavy work behind the scenes" without really doing much.
documentFragment also was used for constructing the elements before appending the fragment to the main element :) I am wondering if that technique has any merit today, since it really helped back then.
What is old will be new again :)
Re: Scheduling in React
#39We used this technique in the IE6 days (with settimeout nonetheless). We had a very big list that was being filtered as the user typed, and we would perform 10 dom operations (they were all creating and appending elements to the dom), then timeout for 15ms, then 10 more operations, etc. If the user changed the text, we would clear the most recent timeout which would stop the chain, it was very clean actually. I suppo…
Oh, it goes back quite a bit further than that :)
Re: Scheduling in React
#40I 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
We’ll end up with threads in JS one day.