You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm curious about the naming of AsyncLocalStorage in Node.js. In Go, for example, there's a context standard library, which feels more intuitive when dealing with asynchronous context management. However, in Node.js, the API is named AsyncLocalStorage.
Why was this name chosen instead of something more straightforward like Context or ContextObject similar? Some developers find the current naming confusing or even misleading, as it doesn't immediately convey the idea of managing asynchronous execution context.
Is there any historical or technical reason behind this naming choice? Would it be possible to align with a more conventional term like Context or AsyncContext, which might be clearer for developers familiar with similar patterns in other languages?
The text was updated successfully, but these errors were encountered:
The naming was chosen to align conceptually with the term "thread local storage" and it wouldn't be practical or helpful to the ecosystem as a whole to rename it at this point.
Also, changing the name to AsyncContext would conflict with the TC39 proposal of the same name. That even does the same thing (roughly) so the API mismatch would be very bad for standards adherence.
Affected URL(s)
https://nodejs.org/api/async_context.html
Description of the problem
I'm curious about the naming of AsyncLocalStorage in Node.js. In Go, for example, there's a context standard library, which feels more intuitive when dealing with asynchronous context management. However, in Node.js, the API is named AsyncLocalStorage.
Why was this name chosen instead of something more straightforward like Context or ContextObject similar? Some developers find the current naming confusing or even misleading, as it doesn't immediately convey the idea of managing asynchronous execution context.
Is there any historical or technical reason behind this naming choice? Would it be possible to align with a more conventional term like Context or AsyncContext, which might be clearer for developers familiar with similar patterns in other languages?
The text was updated successfully, but these errors were encountered: