Isn't this some of what Fiber was supposed to take care of?
Scheduling in React
41–50 of 109 posts
Re: Scheduling in React
#42There'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.
I read the Redux site for the first time recently and I realised that it is a transliteration of the Elm architecture (TEA). TEA is probably easier to understand first as it fits more nicely into its native Elm than Redux does into JS.
I think Redux is quite simple conceptually, but if you just look at the code without the concept and reason behind it, it’ll look like complexity for the sake of it.
Re: Scheduling in React
#43Earlier 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…
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]…
Yes, I'm familiar with the arguments against it, but my experience using Redux has led me to strongly disagree with them. I don't think the proposed benefits have much value in actual practice, and limiting the use of dispatch to plain objects makes state logic easier to understand in my opinion.
Also, I think my primary issue with redux-thunk isn't that you dispatch a non-object but that the getState argument encourages async operations which are dependent on the current store state, possibly its current state at multiple different points of time. Personally I think that as much as possible async operations should be written to use only parameters as input and dispatch actions as output.
Plus I use TypeScript where things like this getState argument are really annoying for strong typing. You need to import the type of your store or store state in every file that uses a thunk.
I also personally think that the extra ceremony applied to Redux is a contributor to the difficulty new developers have understanding it, because they believe that Redux does more than it actually does.
Re: Scheduling in React
#44Isn't this some of what Fiber was supposed to take care of?
"Fiber" was the codename for the internal rewrite that was completed and delivered as React 16.0.
That rewrite has enabled all of the further functionality that's been implemented in 16.x, including the first stages of "Concurrent Mode".
Re: Scheduling in React
#45We 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 :) https://blog.codinghorror.com/is-doevents-evil/
Hah, of course, spoke too soon! And it's by Jeff Atwood!
I got the idea back then from some game devs who used a variation of this technique (though theirs was a queue mechanism for prioritizing disk reads to speed up loading of important assets and defer the rest in the old magnetic days). Anyway, congrats to the react team, really cool.
I am wondering if they plan to abstract it completely so that everyone uses it without even realizing it.
Re: Scheduling in React
#46Impressive, 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.
People are highly aware of when their input is locked up. It's like trying to type commands over SSH on a bad or laggy connection: you have to keep pausing, wait for it to catch up, and ensure there are no typos or anything. Oops, need to backspace, wait, and edit that character. Oops, backed up too far.
Classic example of this is a naive markdown preview box that updates on every keypress. As the input grows, the experience becomes more intolerable until you're left typing the post in notepad and pasting it into the .
You are only able to look past it here because of the contrived example. Though I found the demonstration intolerable and would hope, as a user of your application, that you wouldn't settle on "meh, the user won't notice/care." Especially since you don't notice it on your developer workstation and I'm stuck using it from my low powered mobile device.
Re: Scheduling in React
#47Earlier quoted context omitted.
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]…
Yes, I'm familiar with the arguments against it, but my experience using Redux has led me to strongly disagree with them. I don't think the proposed benefits have much value in actual practice, and limiting the use of dispatch to plain objects makes state logic easier to understand in my opinion. Also, I think my primary issue with redux-thunk isn't that you dispatch a non-object but that the getState argument encour…
I understand most of your concerns, and it seems like we'll have to agree to disagree to some extent.
FWIW, I specifically addressed several concerns regarding use of `getState` in my post "Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability" [0].
I agree that trying to fully capture the potentially dynamic behavior with static types can be painfully difficult. I don't actually use TS myself, yet, but we've definitely had lots of issues pop up related to this (such as [1] ), and I think I get the general issues involved. Unfortunately, I don't have any real suggestions to offer on this front, both because my TS knowledge is limited to "declare types for function params and object fields", and because I'm not sure there _are_ ways around that.
Having said that, our new Redux Starter Kit package [2] is specifically intended to help simplify a number of common Redux use cases, and I'd encourage anyone using Redux to try it out.
Long-term, we plan to revamp the Redux docs content [3], and I hope to improve a lot of the teaching workflow. I also hope to make RSK the "default" way to use Redux for most people.
[0] https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-th...
[1] https://github.com/reduxjs/redux-thunk/issues/231
Re: Scheduling in React
#48You can significantly improve on the baseline performance simply by doing:
handleChange = event => {
const value = event.target.value;
this.setState({ inputValue: value });
setTimeout(() => {
this.props.onChange(value);
}, 1);
setTimeout(() => {
sendAnalyticsPing(value);
}, 1);
};
setTimeout(() => {
miningBitcoin(2);
}, 1);
Re: Scheduling in React
#49We 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…
It's not a new technique. The innovation in React is allowing the framework to pause render on any component boundary, and detect and redo any stale renders when inputs change.
Re: Scheduling in React
#50You can significantly improve on the baseline performance simply by doing: handleChange = event => { const value = event.target.value; this.setState({ inputValue: value }); setTimeout(() => { this.props.onChange(value); }, 1); setTimeout(() => { sendAnalyticsPing(value); }, 1); }; And wrapping mining function inside Name(): setTimeout(() => { miningBitcoin(2); }, 1); In fact, to me this pretty much seems as fast as t…
How does this "improve" at all?
In fact, that example will eliminate any chance React might have of batching multiple updates into a single render pass.
React wraps all event handlers in a call to `unstable_batchedUpdates()`. All updates that are queued in that event handler will be batched together.
Splitting updates into multiple ticks will keep them from being batched.