61–70 of 109 posts
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.
Earlier quoted context omitted.
I do think we need to agree to disagree. That being said according to the README for the Redux Starter Kit these are listed as problems it wants to solve: • "Configuring a Redux store is too complicated" • "I have to add a lot of packages to get Redux to do anything useful" • "Redux requires too much boilerplate code" I can't help but point out that all of these concerns can also be solved by not using any extra libr…
I'd encourage you to read through the RSK docs further to see what all it actually does, then :)
Earlier quoted context omitted.
I'd encourage you to read through the RSK docs further to see what all it actually does, then :)
Sorry, I know you're heavily involved in this ecosystem, I just don't really see the need for any of this. create-react-app is mostly about webpack, isn't it? Redux works fine on its own.
Almost everyone uses `redux-thunk` [1]. Adding that to a plain Redux store takes a few steps. Adding middleware _and_ setting up the Redux DevTools Extension adds another couple steps [2] So, RSK's `configureStore()` does that by default [3].
Accidental mutation is the #1 mistake folks make when writing Redux apps [4]. So, `configureStore()` adds a middleware by default that warns about that mistake [5].
Writing immutable update logic can be difficult, and especially painful if the updates are nested [6]. Also, many folks don't want to use switch statements for some reason [7]. So, we ship a `createReducer()` utility that lets you write "mutative" immutable updates, and define the reducers as a lookup table [8].
Many people don't like writing action types and action creators by hand. So, RSK includes a `createSlice` utility that generates those automatically. [9]
None of these are incredibly ground-breaking. There's lots of existing Redux addons that do similar things. But, we're including all these utilities in an "official" package, and recommending that folks use it.
No one's being forced to use RSK. But, I can say that just about everyone who's seen this has said something similar to "this looks awesome, I can't wait to use this!".
[0] https://github.com/reduxjs/redux/issues/2295
[1] https://blog.isquaredsoftware.com/presentations/2017-09-migh...
[2] https://redux.js.org/recipes/configuring-your-store#integrat...
[3] https://redux-starter-kit.js.org/api/configureStore
[4] https://redux.js.org/faq/react-redux#why-isnt-my-component-r...
[5] https://redux-starter-kit.js.org/api/getDefaultMiddleware
[6] https://redux.js.org/recipes/structuring-reducers/immutable-...
[7] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
Earlier quoted context omitted.
Try it instead of theorizing: https://codesandbox.io/s/07293kpnn The UI is nearly as responsive as their improved example. I'm not a React expert, but I do know that browsers defer timeouts until they have time to process them. This can be used to take heavy-hitting functions out of events that block UI interactions. It can also be used for self-throttling recursive IIFEs.
If you delay the artificial slowness that I added in the Text component after the rendering, it sure will be faster. The point is to simulate an expensive component tree with this. If we keep that in ( https://codesandbox.io/s/93yv4j129p ), my previous comment holds true: https://news.ycombinator.com/item?id=19332577 Here is by the way a version with all artificial slowness removed: https://codesandbox.io/s/9859x0wm9…
This is something setTimeout is incapable of helping with. Because even if you delay the work, at some point it’s still gonna block.
In either case this example is very simplified and doesn’t illustrate the subtle difference as much. We’ll prepare our own examples when the features are stable.
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.
We 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.
We also reuse the same scheduling architecture for waiting for network and other IO. You can watch our latest talks on Concurrent Mode that touch on this here:
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
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
We’ll end up with threads in JS one day.
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.
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