-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Closed
Labels
P4customer-dart-sassdevexp-warningIssues with the analyzer's Warning codesIssues with the analyzer's Warning codeslegacy-area-analyzerUse area-devexp instead.Use area-devexp instead.type-enhancementA request for a change that isn't a bugA request for a change that isn't a bugweb-js-interopIssues that impact all js interopIssues that impact all js interop
Description
Sometimes my needs for a JS API don't match up perfectly with my needs for a Dart API, and I'd like a way to control the shape of my JS API without negatively affecting the Dart API. A way to indicate that a member is only intended for use in JS would go a long way towards making this possible.
I propose that we add an annotation to package:js, perhaps @jsOnly, to indicate this. The analyzer and dev compiler would error if a JS-only member was used in Dart, and it would be an error to annotate an override method as JS-only. It would probably be fine if they were accessible via dynamic dispatch or mirrors, though. Dartdoc also wouldn't emit documentation for JS-only methods.
Metadata
Metadata
Assignees
Labels
P4customer-dart-sassdevexp-warningIssues with the analyzer's Warning codesIssues with the analyzer's Warning codeslegacy-area-analyzerUse area-devexp instead.Use area-devexp instead.type-enhancementA request for a change that isn't a bugA request for a change that isn't a bugweb-js-interopIssues that impact all js interopIssues that impact all js interop