export with get/set option

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

export with get/set option

Michael J. Ryan
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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: export with get/set option

Isiah Meadows-2
I *really* like this idea, especially if you combined it with making
existing `export`s implicitly `get` (to avoid breaking).

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Sun, Oct 28, 2018 at 6:03 PM Michael J. Ryan <[hidden email]> 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/
> [hidden email]
> [hidden email]
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss