RFC: First class support for promises and async/await

[acdlite]

Adds first class support for reading the result of a JavaScript Promise using Suspense:

• Introduces support for async/await in Server Components. Write Server Components using standard JavaScript await syntax by defining your component as an async function.
• Introduces the use Hook. Like await, use unwraps the value of a promise, but it can be used inside normal components and Hooks, including on the client.

This enables React developers to access arbitrary asynchronous data sources with Suspense via a stable API.

View the rendered text

[dai-shi]

What would be the naming convention for functions only with use?

const customFunctionThatCanBeCalledConditionallyButOnlyInRender = (p, c) => {
  return [use(p), use(c)];
};

It can't be useFoo as eslint rule check will be false positive. So, no naming convention?

[acdlite]

What would be the naming convention for functions only with use?

use is the only Hook that's allowed to be called conditionally. And you can only call use from inside another Hook (or component).

(There was a sentence in the RFC that I think made this a bit ambiguous; I tweaked it so it's hopefully clearer.)

Calling from a non-Hook will "work" in the runtime, but the linter will forbid it. It's the same restriction as other Hooks: use is only permitted inside components and other custom Hooks.

It's an intentional decision that this proposal would effectively prevent arbitrary function calls from being allowed to suspend. There are a few reasons for this, one of them being that it allows an auto-memoizing compiler to more effectively reuse computations.

But arguably the primary reason is the concern you just raised: it makes it easier to tell which functions are allowed to call it.

Relevant sections of RFC:

• Conditionally suspending on data
• Why isn't use called something more specific?

[dai-shi]

Ah, I missed that part. So, we can't hide use within another function. It's a very unfortunate limitation from the runtime solution perspective, but maybe required for the compiler.

[tom-sherman]

If I have a call like use(getData()), my getData function will be called when React replays the component. What is the intended way to prevent this, if for example performance was a problem?

Also, the component is supposed to be deterministic but doesn't calling a function that almost certainly uses IO introduce non-determinism?

[phryneas]

You could probably do something like

const promise = useMemo(() => getData())
comst result = use(promise)

Also, the component is supposed to be deterministic but doesn't calling a function that almost certainly uses IO introduce non-determinism?

Those functions should probably not generally blindly make new function calls, but be part of a caching solution that checks if there is already a request going on (or more broadly: if one is necessary) and only then make the request.

Generally: React components should render towards a result, but they are not side-effect free. Something like that could have a side effect like reading data from a server, but if you have a side effect that actively changes data somewhere, that should always be part of a user interaction and not part of the component render.

[tobias-tengler]

I think this is where the cache will come into play that's mentioned throughout the document. You should get more info on this, once its RFC drops.

[acdlite]

Also, the component is supposed to be deterministic but doesn't calling a function that almost certainly uses IO introduce non-determinism?

I think this is where the cache will come into play that's mentioned throughout the document. You should get more info on this, once its RFC drops.

Yeah you're meant to cache all IO. The cache RFC will cover this in detail — the basic idea is there will be a built-in, drop-in API you can use to cache any async/IO operation. I'll update this proposal once that RFC is ready.

[jonklein]

It seems like this could be made more explicit (and eliminate the explicit caching burden on the developer) with an API change and a dependency array similar to useEffect:

use(() => myAPI.fetch(id), [id])

[markerikson]

Brian Vaughn joined Replay ( https://replay.io ) a few months ago, and we've been intentionally using pre-alpha/experimental Suspense behavior for data fetching. The pattern Brian introduced is a "Suspense cache", which primarily uses a Wakeable type (basically a sync promise) and then throws it to trigger Suspense behavior:

• replay-devtools: /suspense caches folder
• Reusable createGenericCache implementation

We also have helpers that allow us to fetch data in a typical async function, such as from a Redux thunk.

Typical usage looks like:

// Suspense in a component
function ColumnBreakpoints(props) {
  // actually fetch and suspend
  
  const breakpoints = getBreakpointPositionsSuspense(replayClient, focusedSourceId, visibleLines);

  // rendering
}

// In an async function such as a thunk
export function selectNode(nodeId: string, reason?: SelectionReason): UIThunkAction {
  return async (dispatch, getState, { ThreadFront, replayClient, protocolClient }) => {

    const nodes = await getNodeDataAsync(
      protocolClient,
      replayClient,
      ThreadFront.sessionId!,
      ThreadFront.currentPause!.pauseId!,
      { type: "parentNodes", nodeId }
    );

    // more logic
  }
}

Again, to be clear, we're very knowingly using pre-pre-alpha / experimental behavior here :) and we've come up with a couple custom abstractions like this createGenericCache API for our own use.

Given that, a few questions / concerns from reading this:

• The React team has previously talked about this "Promise cache" pattern along the lines of SomeDataCache.read(id), where that cache would itself throw the promise if the data doesn't exist yet and it starts a request. I know this RFC talks about a future cache API, but doesn't go into details yet. If use is the replacement for the existing-but-now-deprecated "throw a promise" behavior, is the SomeDataCache.read(id) pattern no longer a goal or planned usage approach? Or is it that the "Promise cache" would exist and just return the promise instead of throwing it?
• We've definitely got plenty of cases in our codebase where logic outside of React needs to trigger data fetching, which may then tie into Suspense rendering. Any direction on how that would be done here?
• The restriction on "no use calls in other functions" feels very restrictive at first glance, although I don't have concrete counter-examples off the top of my head

[acdlite]

@markerikson #229 (comment)

The React team has previously talked about this "Promise cache" pattern along the lines of SomeDataCache.read(id), where that cache would itself throw the promise if the data doesn't exist yet and it starts a request. I know this RFC talks about a future cache API, but doesn't go into details yet. If use is the replacement for the existing-but-now-deprecated "throw a promise" behavior, is the SomeDataCache.read(id) pattern no longer a goal or planned usage approach?

cache will be the built-in cache API — it's an evolution of the experimental <Cache /> API that is currently in the experimental channel. It has different implementation details but if you're currently using <Cache /> then cache should fit your needs just as well.

Or is it that the "Promise cache" would exist and just return the promise instead of throwing it?

Yeah you would return the promise, then the caller would unwrap it with use. It might feel a bit strange at first if you're used to the old Suspense pattern, but it's not that different from how you would write code in the async/await paradigm.

We've definitely got plenty of cases in our codebase where logic outside of React needs to trigger data fetching, which may then tie into Suspense rendering. Any direction on how that would be done here?

Yeah the cache RFC will cover this, too. You'll be able to call it from outside React (inside regular async/await code) and then reuse the cached response during rendering.

[acdlite]

@dai-shi #229 (comment)

Ah, I missed that part. So, we can't hide use within another function. It's a very unfortunate limitation from the runtime solution perspective, but maybe required for the compiler.

It would also just be really hard to keep track of which functions are only called inside React functions, without a solid naming convention. We could introduce a new naming convention that's different from hooks but it doesn't seem worth adding yet-another special type of function for only this case.

In practice I don't think it will feel that limiting, just as it's usually not a big deal that custom Hooks can't be conditional.

[iamakulov]

Would React consider naming those fields differently – or maybe putting those fields behind a symbol?

// Just an example, not necessarily these names:
promise._reactState.status
promise._reactState.value
promise._reactState.reason

// Or using a symbol:
promise[React.PromiseState].status
promise[React.PromiseState].value
promise[React.PromiseState].reason

Otherwise,

...if JavaScript were to ever adopt a standard API for synchronously inspecting the value of a promise...

five years down the road, that API might be limited by choices React made today. (See e.g. [].flatten() that had to be renamed to [].flat(), etc.)

[acdlite]

Yeah, we're aware of the flat debacle. I will say it's a little different from what happened with MooTools, though, because we're not modifying the global prototype. Though you're right that it does have implications for future standardization.

The reason we don't want to use private properties, symbols, or React-specific fields is because we want non-React libraries to be able to access these fields, too. It's better for everyone if we all align on the same convention.

Ideally, yes, this would be part of the language. That would be so nice! Would save us so much implementation complexity.

One could argue this is a mildly provocative stance for us to take, but we're hoping if there's enough traction this will motivate the standards bodies to pick up the feature — there seems to have been no traction, despite many proposals over the years, going back to at least 2016 when @sebmarkbage proposed this to TC39.

I also think there's a reasonable way for the standards bodies to workaround this if it becomes an issue: use a reflection-based API like Promise.inspect, instead of direct properties. That's the design I would probably propose anyway, since this is really meant to be used by framework or library code, not in your regular application logic.

[mortargrind]

React-specific fields is because we want non-React libraries to be able to access these fields, too. It's better for everyone if we all align on the same convention.

I am confused about the non-React libraries, can you provide some examples? Wouldn't those libraries be aware of that they are processing something coming from React, despite being a non-React library? If so, can't they just import your Symbol to access these new things?

[glenjamin]

Would you consider using Symbol.for to avoid potential collisions with "normal" JS, while still making the value available to libraries that don't depend on React?

[samuelhulla]

The reason we don't want to use private properties, symbols, or React-specific fields is because we want non-React libraries to be able to access these fields, too. It's better for everyone if we all align on the same convention.

This confuses me a little. Isn't the use primitive even described in the RFC as still a hook requiring a react runtime (to quote "it's still a Hook because it only works when React is rendering." and while allowing conditional suspension inside (i.e. if) blocks, this would still be essentially unusable outside of the react architecture?

Or are you simply referring to the fact, that you want library authors to be able to access the unwrapped "use-mutated" Promise primitive?

[iamakulov]

The plan is to implement support for async Client Components in the runtime, but log a warning during development.

This sounds like you want to discourage async Client Components but not outright prohibit them. (Otherwise, you’d throw an error instead of logging a warning.)

Why this choice? (Just curious.)

[acdlite]

Does the explanation below make sense?

The main reason we're discouraging async Client Components is because it's too easy for a single prop flow through the component and invalidate its memoization, triggering the microtask dance described in an earlier section. It's not so much that it introduces new performance caveats, but it makes all the performance caveats described above much more likely.

[iamakulov]

Nah, saw that :(

Let me try rephrasing the question. If you want to discourage async client-side components, why not prohibit them completely? (By throwing an error if you encounter an async client component, for example. Right now, as the RFC says, you’re just logging a warning during development.)

Is that because you still want people to experiment with async client components? Some other reason?

[acdlite]

Yeah it's so frameworks like React Router or Next.js could experiment with them:

There is one pattern where we think async Client Components make sense: if you structure them in such a way that they're guaranteed to only update during navigations. But the only realistic way to guarantee this in practice is by integrating support directly into your application's router.

The warning won't fire during a transition, so if your framework can guarantee that, it will work.

[Noriller]

Wouldn't it be possible to move async Client Components to a worker thread that could just stream the jsx back to main thread?
Instead of having two different set of components (server and client), we could just write it one way and have react delegate those components to a thread when it's not running in a server.

[tom-sherman]

@Noriller That wouldn't have the semantics I'd expect from an async client component. You can only transfer values that are structural cloneable over the worker boundary, which means no functions for example.

Having said that, it is possible to run server components in a worker today but you of course keep all of the server component semantics.

[markerikson]

Some reactions over in the Reddit /r/reactjs thread:

https://www.reddit.com/r/reactjs/comments/y30uga/react_rfc_first_class_support_for_promises_and/

[martinheidegger]

For proper support of async / await in the client I would assume first-class support of AbortSignals:

// if a function is passed instead of a promise, it will be called with a signal.
// upon "unrendering" of the component the signal is aborted. 
const note = use(({ signal }) => fetchNote(id, { signal }));

Also, with the proposed API I am wondering how to distinguish an empty result form a finished result:

const note = use(Promise.resolve(undefined))

maybe a different API would prevent future head-aches and workarounds?

const { state, result, error } = use(Promise.resolve(undefined))
if (state === 0) // waiting
if (state === 1) // successful
if (state === -1) // errored

[acdlite]

@martinheidegger #229 (comment)

For proper support of async / await in the client I would assume first-class support of AbortSignals

There is an experimental version of this we implemented behind a flag, but it's more related to the cache proposal that we're working on. (I do apologize that proposal isn't ready yet — we're aware that a lot of the questions that are coming up are hard to answer without more knowledge of how caching works.) We do see the value but we'd need to figure out what the lifetime of the signal is — for example, does it live for as long as the response is cached, or only until it finishes?

[eugeneo]

With suspend status will never be "waiting". Just success/error. Error can be thrown. Can we have ErrorBoundary in hooks API?

react-query does a great job with promises.

[acdlite]

@eugeneo #229 (comment)

With suspend status will never be "waiting". Just success/error. Error can be thrown. Can we have ErrorBoundary in hooks API?

The status for that is "pending" — if you read a promise that's still pending, it will suspend and trigger the nearest Suspense fallback.

If the status is "error" it will trigger the nearest error boundary.

react-query does a great job with promises.

Libraries like React Query can essentially work the same as they do today. They can either use use internally, or they can return a promise to the caller, and then the caller would unwrap the result of the promise with use.

[tobias-tengler]

Libraries like React Query can essentially work the same as they do today. They can either use use internally, or they can return a promise to the caller, and then the caller would unwrap the result of the promise with use.

const promise = useQuery(...);
const data = use(promise);

feels like a very clunky user-facing API, so I don't think it will catch on.

Just to get this right though: The ability to call use conditionally will be lost, once exposed as part of a custom hook? A useQuery hook for example, built on top of use, won't be callable conditionally, right?
I understand use and cache very much as primitives that regular users shouldn't or shouldn't have to interact with. Most of the time they will be an implementation detail of some 3rd-party solution or data fetching abstraction.
I feel like use's ability to be called conditionally would be used as an escape hatch to the established hooks behavior: "Would be great if I could just do this fetch here conditionally, but our established useData hook won't allow me to" "Ah right, use can be called conditionally, maybe I can just use it for this one special case" ... Time passes, system gets out-of-sync, yadda yadda yadda...

If use's ability to be called conditionally is lost in 90% of real world use cases, where it is abstracted, why even divert from established patterns? What are your thoughts?

[bvaughn]

cache will be the built-in cache API — it's an evolution of the experimental <Cache /> API that is currently in the experimental channel. It has different implementation details but if you're currently using <Cache /> then cache should fit your needs just as well.

Fortunately, Replay's use case is able to use module-level caching for most of our Suspense data, so we sidestep a lot of complexity.

[bvaughn]

This means only Hooks will be allowed to suspend.

At first I was confused and concerned about the "only Hooks" statement, until I saw:

The only requirement is that the parent function must be a React component or Hook

😄

[bvaughn]

Why? This seems like it could be pretty awkward in practice. (Easy to forget about.)

Is this constraint being imposed to increase the likelihood of being able to port to a more native approach in the future?

[acdlite]

Yeah that's one reason. It makes it easier for a compiler to optimize this. Note that it's the same restriction that applies to await in async functions and yield in generators.

The other benefit is that we think it'd be too hard to track whether you're inside a non-React function without a solid naming convention:

If we allowed use to be called in regular functions, it would be up to the developer to keep track of whether it was being in the right context, since there's no way to enforce this in the type systems of today. That was one of the reasons we created the "use"- naming convention in the first place, to distinguish between React functions and non-React functions.

[...]

We could introduce a separate naming convention that's different from hooks, but it doesn't seem worth adding yet-another type of React function for only this case. In practice, we don't think it will be a big issue, in the same way that not being able to call Hooks conditionally isn't a big deal.

[bvaughn]

Rather than suspend, React will wait for the microtask queue to flush.
If the promise resolves within that period, React can immediately replay the component and resume rendering, without triggering a Suspense fallback.

How do inputs invalidate the cached promise?
If props/state change, those aren't guaranted to be ones that impact the cached promise, but they might.
Why not use ane explicit deps array?

Nevermind. This is clever.

The upcoming cache API looks nice too (at least what you've hinted at)!

[bvaughn]

How do you plan to handle versioning for these non-standard, convention fields?

[acdlite]

Versioning for React? I think the plan is that we don't ever change them :) Our hope is that other libraries adopt the same convention, and then that convinces the standards bodies to address with a built-in JavaScript version. Something like Promise.inspect. But we're aware this is mildly provocative.

[mortargrind]

Considering you are the most popular UI framework out there by a long margin and most probably one of top ten NPM packages downloaded for a really long time by now; properties you add to promises might have huge ramificafions. Even if you dont pollute the Promise prototype and even if it's only your promises. At the end of the day TC39 wont want to break every React application out there when it comes to updating things in the future.

I dont know; I currently dont see any reason against proceeding with a Symbol.

[slorber]

Why not create a dedicated React-agnostic package using symbols instead of attributes? The API would be stable, feature-complete, and usable by other libraries, and you could even improve typing support with an InspectablePromise type

[bvaughn]

Cool!

[acdlite]

@tobias-tengler #229 (comment)

const promise = useQuery(...);
const data = use(promise);

feels like a very clunky user-facing API, so I don't think it will catch on.

In practice we expect it would look more like this:

const data = use(fetchQuery(...));

which you could also call from a non-React function like this:

const data = await fetchQuery(...);

If use's ability to be called conditionally is lost in 90% of real world use cases, where it is abstracted, why even divert from established patterns? What are your thoughts?

The hope is that once use exists, libraries will adapt their APIs to support conditional suspending. I know it seems weird compared to what we're used to but I do think the comparison to async/await is apt. It's basically the same pattern. One day we might literally be able to use async/await directly in Client Components, just as we're currently proposing for Server Components.

[markerikson]

@acdlite I know this is really starting to get over into the territory of the cache API RFC that doesn't exist yet, but what would that sort of "adapted library API" look like?

I'm specifically thinking of the major existing data fetching libs here like Apollo, SWR, React Query, and RTK Query. All of them have settled on a fairly similar useQuery()-style API that returns something like { data, isFetching }.

How would you propose a library expose that same general functionality in a non-hook form?

[acdlite]

@markerikson #229 (comment)

All of them have settled on a fairly similar useQuery()-style API that returns something like { data, isFetching }.

use isn't going to be useful for those APIs anyway, because it requires Suspense. Libraries or APIs that aren't interested in integrating with Suspense can keep doing what they're already doing with their Hook-based APIs.

But presumably some of those libraries have landed on that convention because Suspense for data fetching hasn't been stable until now, and once it is stable (with use) they'll switch to Suspense.

[acdlite]

Also note that it's totally possible to do this:

const promise = useQuery(...);
if (condition) {
  const data = use(promise);
}

maybe with like an opt in flag to return a promise instead of suspending directly. Then you don't have to adopt the cache API, you can just do whatever you're already doing.

It looks clunkier compared to the version that suspends internally but the nice thing is that the user has the option to conditionally suspend based on some other value.

[markerikson]

use isn't going to be useful for those APIs anyway, because it requires Suspense. Libraries or APIs that aren't interested in integrating with Suspense can keep doing what they're already doing with their Hook-based APIs.

That's my point and question, in two ways:

• There's a ton of code in the ecosystem that is using these hooks. Is the expectation that libraries would provide an alternate API, and that the intended path is that ecosystem would stop using useQuery() hooks? That's asking an awful lot and implies a ton of migration.
• Give that these hooks already have a defined result of "some object like {data, isFetching}, returning a Promise from the query hook would be a complete breaking change. I do think a {suspense: true} type option might be more feasible, but even there that would start to wreak havoc with TS types. I could more imagine a useQuery hook calling use() internally.

But this goes back to what I was asking a minute ago.

Given that these hooks exist and have broad adoption, how would you envision an alternate "fetch this data" API for the same library looking like?

[acdlite]

@markerikson #229 (comment)

There's a ton of code in the ecosystem that is using these hooks. Is the expectation that libraries would provide an alternate API, and that the intended path is that ecosystem would stop using useQuery() hooks? That's asking an awful lot and implies a ton of migration.

Well yeah but there's nothing forcing them to migrate immediately. It'll be incremental, like when we introduced Hooks — we didn't delete class components from the universe, but it turned out that enough people liked the new pattern that most of the community eventually switched over.

Ultimately it comes down to whether the community at large finds Suspense compelling enough. If they don't, they can stay with the existing APIs. If they do, then here's a new set of functionality that is unlocked by that.

Given that these hooks exist and have broad adoption, how would you envision an alternate "fetch this data" API for the same library looking like?

Yeah I would probably add a separate API. Similar to when Redux introduced useSelector. That's also the strategy Relay used when they started migrating to Suspense a few years ago.

The two APIs can share internal implementation but the public interface remains clean (e.g. types, as you pointed out).

[aboveyunhai]

The name use is going to be a nightmare for new developers searching for information.

They are going to Google "react use hook" or "use react", and they are going to find nothing.

Please call this something else. Anything else.

Just want to echo this again to make it critical. "use" is an extremely common term in daily searching. Even from the existing useHook().

"how to use/learn react" "how to use react hook", "use react hook", react how to use XXX

"react use hook"? "react usehook"?, "use react use"? "use react use hook"? react use? react use use? react use use hook? react use function ?

when we say "use hook", do you mean use(verb) "react hook" or use() itself, or general useXXXXX() like useState() hook.

This can unintentionally pollute the existing well-established React knowledge map in search engine. You just cannot expect user to use advanced google key word search all the time. (Even in my own sentence I used "use" multiple times 😞).

It will be indeed a nightmare to distinguish the technical meaning and the daily literal meaning.

[mdmathewdc]

The name use is going to be a nightmare for new developers searching for information.
They are going to Google "react use hook" or "use react", and they are going to find nothing.
Please call this something else. Anything else.

Just want to echo this again to make it critical. "use" is an extremely common term in daily searching. Even from the existing useHook().

"how to use/learn react" "how to use react hook", "use react hook", react how to use XXX

"react use hook"? "react usehook"?, "use react use"? "use react use hook"? react use? react use use? react use use hook? react use function ?

This can unintentionally pollute the existing well-established React knowledge map in search engine. You just cannot expect user to use advanced google key word search all the time. (Even in my own sentence I used "use" multiple times disappointed)

It's a valid point right here, seems like this hook was named so without even considering the new developers who are still learning React. Only experienced React developers will understand the use hook if it is named so.

[amannn]

Not sure if this was asked before, but is it expected that use can be called from within an async Server Component? In my opinion, for generic library code that can be executed either in Server or Client Components this would be really helpful to enable a unified API.

I noticed this currently throws an error in Next.js: vercel/next.js#44778. Note that use can be called from within a Server Component, just not if it is marked with async.

import {use} from 'react';

// ✅ Works
export default function ServerComponent() {
  return use(Promise.resolve('Hello'));
}

// ❌ Breaks
export default async function ServerComponent() {
  return use(Promise.resolve('Hello'));
}

I understand that async/await is generally preferred for server components, the point here is having library code just work in Server Components with use being an implementation detail somewhere in library code.

The RFC also mentions:

use actually has less overhead compared to async/await because it can unwrap the resolved value without waiting for the microtask queue to flush.

That would be a nice side effect for my use case since a large number of components will reuse the resolved value.

[dante01yoon]

Not sure if this was asked before, but is it intended that use can be called from within an async Server Component? In my opinion, for generic library code that can be executed either in Server or Client Components this would be really helpful to enable a unified API.

I noticed this currently throws an error in Next.js: vercel/next.js#44778. Note that use can be called from within a Server Component, just not if it is marked with async.

import {use} from 'react';

// ✅ Works
export default function ServerComponent() {
  return use(Promise.resolve('Hello'));
}

// ❌ Breaks
export default async function ServerComponent() {
  return use(Promise.resolve('Hello'));
}

I understand that async/await is generally preferred for server components, the point here is having library code just work in Server Components with use being an implementation detail somewhere in library code.

As I know, nextjs version 13's server component can't be used with hooks. Isn't that error pointing that?

[amannn]

As I know, nextjs version 13's server component can't be used with hooks. Isn't that error pointing that?

Hmm, which hooks are you referring to? E.g. useMemo works fine for me. I guess most hooks don't make sense in Server Components (e.g. useState), so I don't expect them to work.

[pkellner]

With @acdlite leaving Meta, does that mean this pull request will be deferred until after NextJS 13 and the server components release is really wrapped and released? A while back @gaearon said here vercel/swr#1906 (comment) that "server components will release before client side suspense and data fetching will happen in non relay data libraries (or at least that is how I interpret it).

Would it be a correct assumption to assume that Suspense support on the client side with a hook like "use()" in this proposal is not coming out until after Next.js Server components have shipped?

[nickserv]

I can't tell you anything about release timeline, but I've noticed this demo is already consuming a use hook from an experimental React build: https://github.com/reactjs/server-components-demo

[lili21]

is it ready now? I can't wait to see the cache part. 😄

[johnforte]

Since it took me a bit to find it the above experimental repo, here is the link to where use is being called https://github.com/reactjs/server-components-demo/blob/99e49cbb37a6e73aaa0d0751d7cee9217c263c26/src/framework/router.js#L69

[liusong1111]

The name use is going to be a nightmare for new developers searching for information.
They are going to Google "react use hook" or "use react", and they are going to find nothing.
Please call this something else. Anything else.

Just want to echo this again to make it critical. "use" is an extremely common term in daily searching. Even from the existing useHook().

"how to use/learn react" "how to use react hook", "use react hook", react how to use XXX

"react use hook"? "react usehook"?, "use react use"? "use react use hook"? react use? react use use? react use use hook? react use function ?

when we say "use hook", do you mean use(verb) "react hook" or use() itself, or general useXXXXX() like useState() hook.

This can unintentionally pollute the existing well-established React knowledge map in search engine. You just cannot expect user to use advanced google key word search all the time. (Even in my own sentence I used "use" multiple times disappointed).

It will be indeed a nightmare to distinguish the technical meaning and the daily literal meaning.

Absolutely right.
Since use is not a good name, how about reactive(from vue3, if the value can change continuously) or settled(if the value can only resolve once, e.g. promise)?

based on above, cached or ds(data source even with dependency tree and transformer) could be implemented.

[voliva]

I'd like to reiterate the concern on cancellation: #229 (comment)

I think this is a pretty big concern, since use can theoretically start subscriptions that on some cases would never get cleaned up, at least with the current proposal.

It's actually one of the reasons why currently "the render function must be kept side-effect free". use will break this assumption, but then I think it needs to give some mechanism to trigger cancellation in case the component never gets mounted.

[albeniskerqeli10]

Apologies for asking, but is there any update on this RFC? It was introduced nearly a year ago, and yet it hasn't been merged and/or included in a stable version of React.

[nickserv]

Note that while this hasn't been merged into the RFCs yet, it has already been implemented in React canaries (though you'll likely want a meta framework like Next).