List of the 86 React Working Group members built with https://1zbjq.csb.app/.
Things to note to make this work:
- you'll need to have your remix registry token available in your shell under
REMIX_TOKEN
- you'll need to add secrets to your GitHub repo for the following items:
REMIX_TOKEN
VERCEL_TOKEN
(https://vercel.com/account/tokens)VERCEL_ORG_ID
VERCEL_PROJECT_ID
- you'll need to have your
REMIX_TOKEN
available in your vercel repo as an environment variable
To the Gatsby Community,
We want to start by specifically thanking Nat Alison. We support her and commend her bravery in speaking out. It is not easy to stand alone. What she experienced at Gatsby was unacceptable and speaks to wider issues. We thank her for putting pressure on the company to fix them. We vow to double down on those efforts.
While we have worked hard to give feedback and help create a healthy work environment over the past few years, change has been far too slow and the consequences have been real. The previous weeks have intensified the need for rapid change by increasing employee communication and allowing us to collectively connect some dots. We are just as outraged. As a result, we have posed a series of hard questions to management as well as a list of concrete actions they need to take.
Kyle Mathews' public apologies to both Nat Alison and Kim Crayton are small actions swiftly taken that signal the possibility for change but don't speak to the systemic issues that must be addressed.
I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.
I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.
"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.
@broros
otherwise why would he hand over a popular package to a stranger?
If it's not fun anymore, you get literally nothing from maintaining a popular package.
One time, I was working as a dishwasher in a restu
React recently introduced an experimental profiler API. After discussing this API with several teams at Facebook, one common piece of feedback was that the performance information would be more useful if it could be associated with the events that caused the application to render (e.g. button click, XHR response). Tracing these events (or "interactions") would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "How long does it typically take for this interaction to update the DOM?".
With version 16.4.3, React added experimental support for this tracing by way of a new NPM package, scheduler. However the public API for this package is not yet finalized and will likely change with upcoming minor releases, so it should be used with caution.
// jonschlinkert/is-object | |
type IsObjectObject<T> = T extends | |
| AnyArray | |
| AnyFunction | |
| boolean | |
| null | |
| number | |
| string | |
| symbol | |
| undefined |
All libraries have subtle rules that you have to follow for them to work well. Often these are implied and undocumented rules that you have to learn as you go. This is an attempt to document the rules of React renders. Ideally a type system could enforce it.
A number of methods in React are assumed to be "pure".
On classes that's the constructor, getDerivedStateFromProps, shouldComponentUpdate and render.
Method | Side effects1 | State updates2 | Example uses |
---|---|---|---|
Mounting | |||
componentWillMount |
✓ | Constructor equivalent for createClass |
|
render |
Create and return element(s) | ||
componentDidMount |
✓ | ✓ | DOM manipulations, network requests, etc. |
Updating | |||
componentWillReceiveProps |
✓ | Update state based on changed props |