createContext has a non-standard (and not used) argument
See original GitHub issueReproduction
See create-context.js. The value of the contextId
argument appears to be unused. Some compilers, such as Closure error out when migrating. This can normally be ignored, but not clear if it’s justified in this case since the value is unused.
Expected Behavior
The React’s createContext
is declared with one argument.
Actual Behavior
The Preact’s createContext
is declared with two argument and the value of the second argument is not used.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
[@types/react] Remove calculateChangedBits from ...
I've just noticed createContext has a second argument in the type definition. This doesn't make sense and is misleading.
Read more >React.createContext point of defaultValue?
When there's no Provider, the defaultValue argument is used for the function createContext . This is helpful for testing components in ...
Read more >Typing React Context to avoid an undefined default value
The simple solution is to use a non-null assertion “!” that will allow us to tell TypeScript that, during runtime, the parameter will...
Read more >What's New in JMS 2.0, Part One: Ease of Use
Learn how new ease-of-use features enable you to write fewer lines of code. This article, which is the first article in a two-part...
Read more >Context
createContext ; Context. ... createContext('light'); class App extends React. ... The defaultValue argument is only used when a component does not have a ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
A bundler does no code optimizations so that isn’t really its responsibility (unless you are exclusively talking about a compiler in this case closure). That aside, we could probably resolve this differently, thinking about it atm
Certainly. But I do think “typically not in exported methods” is a good standard to follow. W.r.t. to React compatibility. I agree - it’d certainly make sense to diverge APIs where it has semantic meaning. In this case, however, this is purely an implementation detail. E.g. tomorrow it might disappear from the
createContext
with no perceptible API difference but would force strict-compiler users to change their code.