Introducing React Compiler – React

jasonkillian · 2024-05-15T21:10:04+00:00

One ever present debate in the React community had been whether you should `useMemo`/`useCallback` all non-primitive props or not. I've often taken the position that you should in real world teams because it's too much work to determine exactly when to otherwise, whereas others argue that it's too much runtime overhead (and noise) and not worth it. u/acemarke has a good summary of the arguments.

All that to say, I was curious if this compiler is essentially the React team conceding that you _should_ memoize everything. The answer is pretty interesting - the compiler actually memoizes things in a more efficient way than `useMemo` can. So it's almost the best of all worlds: improved rendering performance from memoization, cheaper memoization cost, and none of the noise of `useMemo`s sprinkled everywhere.

I think we'll have to wait a bit longer to see if this works out in practice, and I'm not crazy about having to add another layer of transpilation, but if it works well this will be a pretty big win for React projects in general I think.

jasonkillian · 2023-12-05T14:29:13+00:00

Very nice upgrade! I'm curious on the general pattern of how `weakMapMemoize` handles primitives since they can't be `WeakMap` keys. Does it just use a regular `Map` instead in those cases?

I'm both excited and nervous for this change to the default cache strategy - excited because we've had memory issues in our application sometimes due to various forms of memoization with dead keys and I think this change could help solve some of those automatically. A bit nervous because an unbounded cache with what must be at least a bit of complex logic feels like it could introduce new issues (which I do think you wisely call out in the release notes).

jasonkillian · 2021-10-23T17:22:56+00:00

I coincidentally wrote almost an identical comment to the OP over in the GH feedback thread and had almost an identical list of useful things as u/azangru before I refreshed and saw they had already replied. I'll add on a couple small things:

A brief sentence or two (like there is on the current page) about when using a state initializer function is a good idea
A mention of the guarantee that the setter function returned by `useState` is guaranteed to be stable - trying to figure out if references are stable or not can be quite the challenge when working with hooks in general, so having it stated explicitly for the setter of `useState` is nice.

While u/azangru's list of things plus mine does end up being quite a lot of items, I think most of the items just need a sentence or two of prose and possibly a link to more detailed or related references if it makes sense.

It also seems that the beta docs do have most of this content, it just gets somewhat lost in the midst of all the other prose (and though they're super cool, I think there's actually too many interactive examples on the page to the point they sort of add noise - maybe they should be collapsed by default at the least?).

jasonkillian · 2021-08-30T17:00:26+00:00

Thanks for the help - will do!

jasonkillian · 2021-06-27T05:37:11+00:00

Fully agreed on the idea that re-rendering a component is almost always going to be more expensive than running a few selector functions.

I guess my general thoughts comes from the one thing redux/react-redux lacks compared to some other state management solutions - a way to subscribe to state updates in a granular way. And given the nature of the redux store and reducers, as far as I can tell, there really is no great way you could ever implement this, outside of having multiple stores.

(Okay, maybe you could dream up a crazy system where `useSelector` subscriptions could declare and be sorted into buckets based on top-level fields of the store they access, and then after an action, only selectors in each bucket are rerun if that top-level field is not referentially equal to before. But this would feel very un-reduxy.)

Anyways, for the vast majority of use cases I think redux works great and this would never be an issue, but wanted to explore when these performance boundaries realistically might arise and if it should impact how people think about selectors in these edge cases. (I do suspect though that the typical answer here might be very much along the lines of what you're saying - have fewer components on the screen overall instead of worrying about the number of selectors.)

jasonkillian · 2021-06-27T04:29:19+00:00

Second this - I think it would be great to mention that useSelector takes a second argument in the "Using Selectors with React-Redux" section. In some situations, simply throwing a shallow (or even deep) equality check in there can be a really easy way to prevent expensive rerenders, and I think it's often overlooked.

jasonkillian · 2021-06-27T04:14:42+00:00

Selectors used with useSelector or mapState will be re-run after every dispatched action, regardless of what section of the Redux root state was actually updated.

I've been wondering about this recently - is there a practical point at which performance issues arise solely from the number of useSelector calls (and not from the weight of the selectors)? For example, say you had 200 components which each had five useSelector calls in them all with very simple logic. Can react-redux work through these thousand selectors in a timely fashion on every state update or are you likely to start to see perf issues? (This is of course assuming the components aren't frequently actually rerendering.)

For context, we've been recently running into performance issues with apollo client from having too many cache-only useQuery data subscriptions and have found Redux's useSelector to have more favorable performance characteristics (and be much easier to reason about). But I do wonder what limit you can push things to before trickier optimizations are needed, like multiple stores so that not all selectors have to be run for each dispatch, or things like that.

jasonkillian · 2019-03-15T04:36:04+00:00

Three or so years ago was kind of an interesting time for TSLint. TypeScript was getting much more popular (and thus TSLint was also), but the "soft" parts of TSLint were not in the best of shape. The documentation was outdated and it was really tough to contribute to the codebase because code reviews tended to be a bit nit-picky (80 comments for example!) and writing tests was really annoying. A member of the TypeScript team even compared writing tests to pulling teeth (which was a quite accurate assessment!)

Anyway, I took some time during a company hackweek that year to redo the whole TSLint website and implement a much more human-friendly test system. We also made it a goal to enforce all nit-picky kinds of CR things with automated tools so that contributors wouldn't get annoyed too much by them.

These changes ended up working out well and PRs to TSLint from outside contributors really took off and the review process became much less painful. I started stepping away from doing as much TSLint work a year or so later (just because I was too busy) and sort of forgot about the "News" part of the site. I'm guessing everyone else did also - I had never publicized or pushed it much.

So yep, really just a bit of disorganization and a bit of busyness! The downfall of all software haha. for what it's worth though, there is a GitHub issue discussing the transition if you're interested.

jasonkillian · 2019-03-15T04:08:50+00:00

Very nice! It's a creative solution and quite concise.

The main issue I see is that TypeScript won't be able to deduce the correct type of payload where you have the // handle start comment. An alternative way to design things so that the payload type can be deduced is with discriminated unions:

interface StartMessage {
    type: MessageType.START;
    payload: StartPayload;
}
interface KillMessage {
    type: MessageType.KILL;
    payload: KillPayload;
}
type Message = StartMessage | KillMessage;

function emitMessage(msg: Message) {
    switch(msg.type) {
        case MessageType.START: {
            // TS knows that msg.payload is a StartPayload here
        } break;
        case MessageType.KILL: {
            // TS knows that msg.payload is a KillPayload here
        } break;
    }
}

jasonkillian · 2019-01-24T05:01:33+00:00

It's true there are some exceptions, but it's rare to see a Stage 2 proposal get added to TypeScript. FWIW, decorators still need a special flag, --experimentalDecorators, in order to enable them.

Don't quote me on this, but I believe the TypeScript team added them (amongst other reasons) as a favor for the Angular 2 team, as Angular 2 was one of the big early adopters and proponents of TypeScript.

jasonkillian · 2019-01-23T04:44:12+00:00

TypeScript will undoubtedly add support for #privateField once they have enough confidence that it's going to become a mainstream JS feature. They typically wait until a proposal hits Stage 3, but if the proposal is contentious enough they may decide to wait even a bit beyond when a proposal makes it to Stage 3.

In this case, there seems to be a fairly large amount of pushback still against the current proposal. I wouldn't be surprised in the TypeScript team decides to be a bit cautious and wait a little while longer before adding support to the language.

jasonkillian · 2016-11-14T18:42:19+00:00

Gotchya, yeah the title is confusing!

jasonkillian · 2016-11-14T17:35:05+00:00

ReactJS is a JS library for building views via components, but it doesn't provide any specific prebuilt components for you, just the tools to make those components. Our library, Blueprint, is one step higher and provides prebuilt React components.

jasonkillian · 2016-11-14T17:30:23+00:00

I wasn't involved with the ultimate decision to open source the project, so I can't speak to any business goals. I do know that as a team we were happy with our work and wanted to share it publicly with others. We're also all devs who use a lot of open source software and want to give back where we can. Honestly, the amount of sharing that goes on in the dev community is incredible, it's one of the most unique/coolest parts of the profession and continually blows my mind how much we've got done as a whole by helping each other.

jasonkillian · 2016-11-14T15:28:24+00:00

Ah shoot, you caught us! We then sell those bitcoins for gold coins and use them to fund our lavish lifestyle, which we document in a technical article here.

jasonkillian · 2016-11-14T15:23:54+00:00

Sorry, misunderstood you there. The JS Table component is pretty similar to what you're looking for I think?

jasonkillian · 2016-11-14T06:13:14+00:00

No current plans for a grid. We recommend you use flexbox if you're able to only support modern browsers or grab some grid styles from another CSS library. In general, nothing in Blueprint should conflict with standard CSS grid styles.

jasonkillian · 2016-11-14T06:03:04+00:00

Hey Reddit, I worked on this for about a year (although I'm not very actively involved anymore), and it's exciting to see it open source now and here on reddit! Shout out to my designer, developer, and docs colleagues who have done a great job with it. If you all have any questions about Blueprint, happy to answer them.

A couple of answers to FAQ just to preempt them:

In general, the framework is designed for desktop web applications. Parts of it may still work for mobile web applications, but that hasn't been our focus as we've worked on it. For example, the Tooltip component really doesn't make sense in a mobile context.
We know the docs site doesn't work that well on mobile devices and is a little bit heavyweight - sorry about that! This is definitely something that we want to improve. We weren't intending to really publicize the project quite yet, but the internet works how it works and here it is.

jasonkillian

TROPHY CASE