Unless of course you needed to export a "features" AND support this magic symbol.
On Thursday, 15 October 2015, Ron Buckton <[email protected]> wrote: > Wouldn’t this work? > > > > our-symbols.js: > > ```js > > export const SpecialSymbol = Symbol("SpecialSymbol"); > > ``` > > > > their-consumer.js > > ```js > > import { SpecialSymbol } from "our-symbols"; > > > > export const features = { > > [SpecialSymbol]: true > > }; > > ``` > > > > our-features.js > > ```js > > import { SpecialSymbol } from "our-symbols"; > > import { features } from "their-consumer"; > > > > if (features[SpecialSymbol]) { > > // … > > } > > ``` > > > > This uses an export named “features”, though in practice it’s pretty much > the same as using “export default”. While the “features” identifier could > theoretically be some other “features” with a different meaning, you can > still detect the presence of your special symbol. > > > > Ron > > > > *From:* es-discuss [mailto:[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>] *On > Behalf Of *Francisco Tolmasky > *Sent:* Thursday, October 15, 2015 10:47 AM > *To:* Logan Smyth <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Cc:* [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > *Subject:* Re: Exporting Symbols > > > > There are special features we want to expose if a module defines a certain > key. However, we’d like to not rely on certain names just because there’s > some chance they came up with it themselves. If it was a symbol that we > gave them access to, it would be impossible for this to be the case, they > would have had to grab the symbol from us: > > > > var SpecialSymbol = require(“our-symbols”).SpecialSymbol; > > > > export { whatever as SpecialSymbol } > > > > The difficulty I’m having right now is being torn by two competing “best > practices”: on the one hand, you can’t do what I did above for the runtime > reasons, on the other hand you CAN actually pull it off using the export > default strategy, and in that situation it technically is safer for us to > use our special symbol instead of relying on a string match. > > > > > > On Thu, Oct 15, 2015 at 8:10 AM, Logan Smyth <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > The main issue is that modules are statically analysable and > imports/exports are processed before the module executes, and the behavior > of a symbol is by definition a runtime thing. Until the code executes, > there would be no symbol object, and there would be no way to know what > thing was being imported imported / exported. > > > > The primary benefit of symbols is that they are unique, and cannot collide > unless you have a reference to them. Module exports have full control over > their names and don't have the same collision issues that objects and > classes generally do. What is the benefit you are hoping to get from > exposing these values on symbols instead of string keys? > > > > > > > > On Thu, Oct 15, 2015 at 12:14 AM, Francisco Tolmasky <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > Not sure if it isn’t the case, but it seems the only way to export symbols > right now is: > > > > ```js > > export default { [Symbol(“something”)]: blah } > > ``` > > > > It would be nice if “symbol literals” could somehow be supported. In > particular, I can imagine this sort of thing becoming common: > > > > export { “5.4” as Symbol(“version”) } > > > > Or, even better (but harder since its now more expression): > > > > import VersionSymbol from “symbols" > > export { “5.4” as VersionSymbol } > > > > I’m currently writing an API where there are expected methods stored in > symbols, but this forces exporting one default object instead of being able > to lay them out individual. > > > > Thanks, > > > > Francisco > > > > -- > > Francisco Tolmasky > www.tolmasky.com > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.tolmasky.com&data=01%7c01%7cron.buckton%40microsoft.com%7c2e02643e0d944134b1f708d2d588b34b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2IQQvQqHc7DJeuLKj9fgCknBXv7p56Vct6%2bSNKqL2N8%3d> > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> > > > > _______________________________________________ > es-discuss mailing list > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > https://mail.mozilla.org/listinfo/es-discuss > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.mozilla.org%2flistinfo%2fes-discuss&data=01%7c01%7cron.buckton%40microsoft.com%7c2e02643e0d944134b1f708d2d588b34b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qb3AoRW3sNrU4Fi9l4Jqxcc%2fC%2b7WRRLO7JoeGQ6y1DE%3d> > > > > > > > > -- > > Francisco Tolmasky > www.tolmasky.com > <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.tolmasky.com&data=01%7c01%7cron.buckton%40microsoft.com%7c2e02643e0d944134b1f708d2d588b34b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2IQQvQqHc7DJeuLKj9fgCknBXv7p56Vct6%2bSNKqL2N8%3d> > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
