101–110 of 120 posts
React hooks is influenced by Dan, the author of Redux, not a fan of them both
IMO Hooks is the best thing that happened to React. Once you get used to it it is a lot more clean and productive. It requires you to unlearn a few things though, e.g. don't think about component lifecycles, but think about data flow/changes. Once you get used to it is a lot more productive and enjoyable way of developing React apps.
React hooks is influenced by Dan, the author of Redux, not a fan of them both
Dan here — I don't quite know what you mean by this, but if you're interested in the actual inspiration behind Hooks, you can check out our Prior Art section: https://reactjs.org/docs/hooks-faq.html#what-is-the-prior-ar... . I only worked on documentation and presentation.
Earlier quoted context omitted.
Gatsby is another very popular SSR framework that uses React.
There's no reason to pick gatsby over next nowadays, next can do everything gatsby can and in a sane, reusable manner.
Feature-wise, Next does seem like a superset of Gatsby, especially since it can support server, static and hybrid rendering models. Architecturally, Gatsby does have some advantages. They're not ones that are particularly important to me, but I don't think it's fair to ignore them:
- The plugin model is more sophisticated, and there's a huge ecosystem of them which can solve most common use cases.
- The ability to use a unified data graph means page invalidation and rebuilds upon data changes can be done automatically at a very granular level -- because it's possible to keep track of which pages would be affected by every piece of data.
I'd add that I have issues with both, which leads me more to Next.js because it has a lower level of vendor lock-in compared to Gatsby. Anecdotally, migrating a small site from Gatsby to Next.js replaced 150 Gatsby-related imports with 10 Next.js ones.
Earlier quoted context omitted.
I do think there's a second wave of frameworks coming, because Django/Flask are showing their age a bit. Sanic is/was really popular and I think FastAPI is really promising.
It seems that the main difference you're pointing out is Python's transition from synchronous-only/wsgi to asynchronous/asgi frameworks.
Earlier quoted context omitted.
I think the marketing line of "No new features" could lure people into a false sense of security on this upgrade, even if the breaking changes are minimal. By all means make breaking changes, just maybe tone down the marketing.
How is a very elaborate blog post indicating the what & why considered marketing? In my opinion this goes WAY beyond the usual changelog entry in other repositories.
I think it's important to understand though that React is _marketed_, and unfortunately for many a name as clearly stated as this will likely define their expectations significantly. This could be especially pronounced for those who are less proficient in English.
Earlier quoted context omitted.
That conflicts with HTML syntax, no? is equivalent to .
Which is why the current JSX syntax uses that as a synonym for `disabled={true}`. Agreed that it matches HTML better, but having written an awful lot of `someLongVariableName={someLongVariableName}`, I sure wish I could stop repeating myself there.
Earlier quoted context omitted.
Thanks! Quick summary: Immer is an incredibly useful immutable update library, created by Michel Weststrate (author of MobX). It exports a single function `produce(originalState, updateCallback)`. The callback receives a `draftState` value that _looks_ like your original state, but has been wrapped in an ES6 Proxy. You can then "mutate" the draft all you want. Internally, Immer tracks all the mutations, and the final…
When I first came across Immer, I wasn’t impressed. I though “If you’re going to the trouble of using functional-ish state management, why add a “mutations-like” API in there. Surely you’re “crossing the streams?” But then a couple of weeks later I had to wrangle data in subsections of three “slices“ of state at the same time. Immer lets you focus on just the state you want to change, and hides the problem of maintai…
Immer just does that in a really slick way.
My only concern for using Immer by default in RTK is the potential that someone would learn Redux by osmosis through looking at a codebase where every reducer is doing `state.someField = someValue`, think that actual mutation _is_ the right way to use Redux, and then try to do the same thing in another project and actually mutate data for real.
I can't prevent that, so my only answer was to repeatedly emphasize in this new tutorial that you _must_ do immutable updates, and that you can _only_ "mutate" inside of RTK's APIs thanks to Immer:
- https://redux.js.org/tutorials/essentials/part-2-app-structu...
- https://redux.js.org/tutorials/essentials/part-3-data-flow#s...
But yeah, the massive improvements in code size and readability are more than sufficient to justify the small potential downside there.
Earlier quoted context omitted.
`redux@^4` currently has two dependencies: `symbol-observable` for compat with observable libs, and `loose-envify` for compat with Browserify. I plan on removing both of those when we release Redux v5. Our official Redux Toolkit package [0], which is now our recommended approach for writing Redux logic, _does_ have a few more deps: Immer, Reselect, Redux-Thunk, and the Redux core. But, those are all things you probab…
> I plan on removing both of those when we release Redux v5. Gasp! Will redux store no longer be an observable then?