I *really* like this idea, especially if you combined it with making existing `export`s implicitly `get` (to avoid breaking).
----- Isiah Meadows [email protected] www.isiahmeadows.com On Sun, Oct 28, 2018 at 6:03 PM Michael J. Ryan <[email protected]> wrote: > > I mentioned something similar to this before, but wanted to update with some > more thoughts on why it could be useful... In my specific case, I have the > following scenario... > > I have a "base" script that loads build values into window.__BASE__, the > application in question is deployed on multiple clients, so strings and other > configuration values are different. The configuration project is built > separately and the correct configuration is built with CI/CD. There are > other configuration options that are loaded via the API that are client > configurable. I know it's a bit different of a use case, but it can't be > *that* unique. I also understand that it's a minefield of mutation, but it's > pretty centrally controlled early, and simplifies a *LOT* of the rest of the > application. > > For example, I currently have the following in my "base.js" reference inside > my project... > > // ------- BEGIN JS > const base = window.__BASE__ || {}; // config from release > > export const environment = base.environment || 'internal.dev'; > export const api = base.api || 'https://api.app.dev-domain'; > // ... other constants exported from base with defaults .... > > // value loaded from API before the SPA UI takes over from a spinner > export let petitionOptions = null; > export const setPetitionOptions = options => { > // client manipulation/integration here > petitionOptions = options; > }; > // ------- END JS > > It would be nice imho if I could do the following... > > > // ------- BEGIN JS > let _petitionOptions; > export { // no identification here, nested in object > get petitionOptions() {...}, > set petitionOptions(value) {...} > }; > > // alternately > export get petitionOptions() {...} > export set petitionOptions(value) {...} > // ------- END JS > > Even more, would be the ability to do other exports via export { name:value } > in an object. While the former method does work, I just think having a > getter/setter interface would be an interesting flexibility... Not sure how > difficult a change it would be to making import variables assignable and > allowing the set transparently. > > thoughts? > > -- > Michael J. Ryan > 480-270-4509 > https://www.tracker1.info/ > [email protected] > [email protected] > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
