Make an IIFE return variables for only some other IIFES
I was wondering if we can declare a variable in one IIFE and the return it but make it available for another specific IIFE? Here is an example!
So I have
const iife1 = (()=>{
const x = 10;
return x
})()
const iife2 = (()=>{/* MAKE X AVAILABLE ONLY IN THIS FUNCTION */})()
const iife3 = (()=>{/* HERE X CANNOT BE CALLED */})()
Maybe you would say just not to pass the variable x in the iif3 as an argument, but I was wondering if there is a conditional way we can achieve it when returning the variable from iif1, so the iif1 will know for which functions it returns its properties or methods before actually has returned!
My goal is to create an IIFE which in it I will declare all the variables that I am going to use in my project. Then for each variable, I want to have a proper condition so that when the IIFE with the variables returns the function has already decided in which scope will sent the variables for use! I don't know if this approach makes sense but as is always being said I am trying not to populate the global scope.
Codepen
javascript scope iife
add a comment |
I was wondering if we can declare a variable in one IIFE and the return it but make it available for another specific IIFE? Here is an example!
So I have
const iife1 = (()=>{
const x = 10;
return x
})()
const iife2 = (()=>{/* MAKE X AVAILABLE ONLY IN THIS FUNCTION */})()
const iife3 = (()=>{/* HERE X CANNOT BE CALLED */})()
Maybe you would say just not to pass the variable x in the iif3 as an argument, but I was wondering if there is a conditional way we can achieve it when returning the variable from iif1, so the iif1 will know for which functions it returns its properties or methods before actually has returned!
My goal is to create an IIFE which in it I will declare all the variables that I am going to use in my project. Then for each variable, I want to have a proper condition so that when the IIFE with the variables returns the function has already decided in which scope will sent the variables for use! I don't know if this approach makes sense but as is always being said I am trying not to populate the global scope.
Codepen
javascript scope iife
2
meta.stackexchange.com/questions/66377/what-is-the-xy-problem
– Jonathan
Nov 12 '18 at 18:26
The IIFE doesn't know about anything, it just gets evaluated when assigning the value foconst iife1
. You could (should?) equally have writtenconst iife1 = 10;
. (It's weird that you call this variable an "IIFE" though)
– Bergi
Nov 12 '18 at 18:45
add a comment |
I was wondering if we can declare a variable in one IIFE and the return it but make it available for another specific IIFE? Here is an example!
So I have
const iife1 = (()=>{
const x = 10;
return x
})()
const iife2 = (()=>{/* MAKE X AVAILABLE ONLY IN THIS FUNCTION */})()
const iife3 = (()=>{/* HERE X CANNOT BE CALLED */})()
Maybe you would say just not to pass the variable x in the iif3 as an argument, but I was wondering if there is a conditional way we can achieve it when returning the variable from iif1, so the iif1 will know for which functions it returns its properties or methods before actually has returned!
My goal is to create an IIFE which in it I will declare all the variables that I am going to use in my project. Then for each variable, I want to have a proper condition so that when the IIFE with the variables returns the function has already decided in which scope will sent the variables for use! I don't know if this approach makes sense but as is always being said I am trying not to populate the global scope.
Codepen
javascript scope iife
I was wondering if we can declare a variable in one IIFE and the return it but make it available for another specific IIFE? Here is an example!
So I have
const iife1 = (()=>{
const x = 10;
return x
})()
const iife2 = (()=>{/* MAKE X AVAILABLE ONLY IN THIS FUNCTION */})()
const iife3 = (()=>{/* HERE X CANNOT BE CALLED */})()
Maybe you would say just not to pass the variable x in the iif3 as an argument, but I was wondering if there is a conditional way we can achieve it when returning the variable from iif1, so the iif1 will know for which functions it returns its properties or methods before actually has returned!
My goal is to create an IIFE which in it I will declare all the variables that I am going to use in my project. Then for each variable, I want to have a proper condition so that when the IIFE with the variables returns the function has already decided in which scope will sent the variables for use! I don't know if this approach makes sense but as is always being said I am trying not to populate the global scope.
Codepen
javascript scope iife
javascript scope iife
edited Nov 12 '18 at 19:31
asked Nov 12 '18 at 18:20
Evan
88
88
2
meta.stackexchange.com/questions/66377/what-is-the-xy-problem
– Jonathan
Nov 12 '18 at 18:26
The IIFE doesn't know about anything, it just gets evaluated when assigning the value foconst iife1
. You could (should?) equally have writtenconst iife1 = 10;
. (It's weird that you call this variable an "IIFE" though)
– Bergi
Nov 12 '18 at 18:45
add a comment |
2
meta.stackexchange.com/questions/66377/what-is-the-xy-problem
– Jonathan
Nov 12 '18 at 18:26
The IIFE doesn't know about anything, it just gets evaluated when assigning the value foconst iife1
. You could (should?) equally have writtenconst iife1 = 10;
. (It's weird that you call this variable an "IIFE" though)
– Bergi
Nov 12 '18 at 18:45
2
2
meta.stackexchange.com/questions/66377/what-is-the-xy-problem
– Jonathan
Nov 12 '18 at 18:26
meta.stackexchange.com/questions/66377/what-is-the-xy-problem
– Jonathan
Nov 12 '18 at 18:26
The IIFE doesn't know about anything, it just gets evaluated when assigning the value fo
const iife1
. You could (should?) equally have written const iife1 = 10;
. (It's weird that you call this variable an "IIFE" though)– Bergi
Nov 12 '18 at 18:45
The IIFE doesn't know about anything, it just gets evaluated when assigning the value fo
const iife1
. You could (should?) equally have written const iife1 = 10;
. (It's weird that you call this variable an "IIFE" though)– Bergi
Nov 12 '18 at 18:45
add a comment |
3 Answers
3
active
oldest
votes
One of the (probaby dozen) ways to achieve that is by using a Proxy
.
First IIFE would create a proxy object through which you'd access its properties. After calling the revoke()
, you will no longer be able to access any of the proxy's props.
As people have stated in their comments, there are probably much easier ways for you to achieve the wanted result, but you haven't presented the actual problem clearly.
const { proxy, revoke } = (() => {
const x = { test: 'test' };
const revocable = Proxy.revocable(x, {
get: (target, name) => name
});
return revocable;
})();
const test1 = (proxy => {
console.log('TEST 1', proxy.test);
})(proxy);
revoke();
const test2 = (proxy => {
console.log('TEST 2', proxy.test); // can't access
})(proxy);
Fiddle:
https://jsfiddle.net/ay92L1r6/6/
I am really not aware what Proxy actually does or how it works. I would definitely check it! Though check the post again I made some updates!
– Evan
Nov 12 '18 at 19:30
If each IIFE is using its own part of theconfig
, is there a reason why you wouldn't create each of the config objects under each IIFE?
– Davion
Nov 12 '18 at 19:59
So the concept of creating a separate module for just declaring variables is not a good idea as far as security and performance concerns?
– Evan
Nov 12 '18 at 21:55
Well, it's not really a question of performance in your specific case, it's just a matter of logic. If you have some configuration object that only one module is going to use, then you should create it locally under that module's scope, so no other can access it. It's a matter of basic scoping.
– Davion
Nov 12 '18 at 23:18
thanks, @Davion. I am gonna make a little bit more research on this.
– Evan
Nov 13 '18 at 11:15
add a comment |
IIFEs can only use Global
, Passed
, or internal variables. You can't make something available to a function scope that isn't available to a second function in the same scope.
Passing variables is one way, but perhaps the more practical way in certain circumstances would be to just nest your IIFEs as needed
const iife2 = (() => {
const iife1 = (() => {
const x = 10;
return x
})()
console.log(iife1);
/*iife2 scope*/
})()
const iife3 = (() => { /* HERE X CANNOT BE CALLED */ })()
add a comment |
It is not necessary to use three IIFE, remember that as soon as your iife1
returns that value will be in the same scope of iife2
and iife3
thus you won't achieve your goal.
Your best bet is to declare iife2
and iife3
as normal functions and call them inside iife1
when some conditions are met and pass the variable that will create the scope of iife3
as argument.
this solution is more flexible and predictable than relying on the outer scope
const fn2 = function(x) {/* MAKE X AVAILABLE ONLY IN THIS FUNCTION */};
const fn3 = function() {/* HERE X CANNOT BE CALLED */};
(()=>{
const x = 10;
//your logic
fn2(x);
fn3();
})()
I don't thinkiife2
andiife3
are functions.
– Bergi
Nov 12 '18 at 18:45
1
you right, i've fixed the example
– Karim
Nov 12 '18 at 18:49
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53267949%2fmake-an-iife-return-variables-for-only-some-other-iifes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
One of the (probaby dozen) ways to achieve that is by using a Proxy
.
First IIFE would create a proxy object through which you'd access its properties. After calling the revoke()
, you will no longer be able to access any of the proxy's props.
As people have stated in their comments, there are probably much easier ways for you to achieve the wanted result, but you haven't presented the actual problem clearly.
const { proxy, revoke } = (() => {
const x = { test: 'test' };
const revocable = Proxy.revocable(x, {
get: (target, name) => name
});
return revocable;
})();
const test1 = (proxy => {
console.log('TEST 1', proxy.test);
})(proxy);
revoke();
const test2 = (proxy => {
console.log('TEST 2', proxy.test); // can't access
})(proxy);
Fiddle:
https://jsfiddle.net/ay92L1r6/6/
I am really not aware what Proxy actually does or how it works. I would definitely check it! Though check the post again I made some updates!
– Evan
Nov 12 '18 at 19:30
If each IIFE is using its own part of theconfig
, is there a reason why you wouldn't create each of the config objects under each IIFE?
– Davion
Nov 12 '18 at 19:59
So the concept of creating a separate module for just declaring variables is not a good idea as far as security and performance concerns?
– Evan
Nov 12 '18 at 21:55
Well, it's not really a question of performance in your specific case, it's just a matter of logic. If you have some configuration object that only one module is going to use, then you should create it locally under that module's scope, so no other can access it. It's a matter of basic scoping.
– Davion
Nov 12 '18 at 23:18
thanks, @Davion. I am gonna make a little bit more research on this.
– Evan
Nov 13 '18 at 11:15
add a comment |
One of the (probaby dozen) ways to achieve that is by using a Proxy
.
First IIFE would create a proxy object through which you'd access its properties. After calling the revoke()
, you will no longer be able to access any of the proxy's props.
As people have stated in their comments, there are probably much easier ways for you to achieve the wanted result, but you haven't presented the actual problem clearly.
const { proxy, revoke } = (() => {
const x = { test: 'test' };
const revocable = Proxy.revocable(x, {
get: (target, name) => name
});
return revocable;
})();
const test1 = (proxy => {
console.log('TEST 1', proxy.test);
})(proxy);
revoke();
const test2 = (proxy => {
console.log('TEST 2', proxy.test); // can't access
})(proxy);
Fiddle:
https://jsfiddle.net/ay92L1r6/6/
I am really not aware what Proxy actually does or how it works. I would definitely check it! Though check the post again I made some updates!
– Evan
Nov 12 '18 at 19:30
If each IIFE is using its own part of theconfig
, is there a reason why you wouldn't create each of the config objects under each IIFE?
– Davion
Nov 12 '18 at 19:59
So the concept of creating a separate module for just declaring variables is not a good idea as far as security and performance concerns?
– Evan
Nov 12 '18 at 21:55
Well, it's not really a question of performance in your specific case, it's just a matter of logic. If you have some configuration object that only one module is going to use, then you should create it locally under that module's scope, so no other can access it. It's a matter of basic scoping.
– Davion
Nov 12 '18 at 23:18
thanks, @Davion. I am gonna make a little bit more research on this.
– Evan
Nov 13 '18 at 11:15
add a comment |
One of the (probaby dozen) ways to achieve that is by using a Proxy
.
First IIFE would create a proxy object through which you'd access its properties. After calling the revoke()
, you will no longer be able to access any of the proxy's props.
As people have stated in their comments, there are probably much easier ways for you to achieve the wanted result, but you haven't presented the actual problem clearly.
const { proxy, revoke } = (() => {
const x = { test: 'test' };
const revocable = Proxy.revocable(x, {
get: (target, name) => name
});
return revocable;
})();
const test1 = (proxy => {
console.log('TEST 1', proxy.test);
})(proxy);
revoke();
const test2 = (proxy => {
console.log('TEST 2', proxy.test); // can't access
})(proxy);
Fiddle:
https://jsfiddle.net/ay92L1r6/6/
One of the (probaby dozen) ways to achieve that is by using a Proxy
.
First IIFE would create a proxy object through which you'd access its properties. After calling the revoke()
, you will no longer be able to access any of the proxy's props.
As people have stated in their comments, there are probably much easier ways for you to achieve the wanted result, but you haven't presented the actual problem clearly.
const { proxy, revoke } = (() => {
const x = { test: 'test' };
const revocable = Proxy.revocable(x, {
get: (target, name) => name
});
return revocable;
})();
const test1 = (proxy => {
console.log('TEST 1', proxy.test);
})(proxy);
revoke();
const test2 = (proxy => {
console.log('TEST 2', proxy.test); // can't access
})(proxy);
Fiddle:
https://jsfiddle.net/ay92L1r6/6/
answered Nov 12 '18 at 19:06
Davion
766410
766410
I am really not aware what Proxy actually does or how it works. I would definitely check it! Though check the post again I made some updates!
– Evan
Nov 12 '18 at 19:30
If each IIFE is using its own part of theconfig
, is there a reason why you wouldn't create each of the config objects under each IIFE?
– Davion
Nov 12 '18 at 19:59
So the concept of creating a separate module for just declaring variables is not a good idea as far as security and performance concerns?
– Evan
Nov 12 '18 at 21:55
Well, it's not really a question of performance in your specific case, it's just a matter of logic. If you have some configuration object that only one module is going to use, then you should create it locally under that module's scope, so no other can access it. It's a matter of basic scoping.
– Davion
Nov 12 '18 at 23:18
thanks, @Davion. I am gonna make a little bit more research on this.
– Evan
Nov 13 '18 at 11:15
add a comment |
I am really not aware what Proxy actually does or how it works. I would definitely check it! Though check the post again I made some updates!
– Evan
Nov 12 '18 at 19:30
If each IIFE is using its own part of theconfig
, is there a reason why you wouldn't create each of the config objects under each IIFE?
– Davion
Nov 12 '18 at 19:59
So the concept of creating a separate module for just declaring variables is not a good idea as far as security and performance concerns?
– Evan
Nov 12 '18 at 21:55
Well, it's not really a question of performance in your specific case, it's just a matter of logic. If you have some configuration object that only one module is going to use, then you should create it locally under that module's scope, so no other can access it. It's a matter of basic scoping.
– Davion
Nov 12 '18 at 23:18
thanks, @Davion. I am gonna make a little bit more research on this.
– Evan
Nov 13 '18 at 11:15
I am really not aware what Proxy actually does or how it works. I would definitely check it! Though check the post again I made some updates!
– Evan
Nov 12 '18 at 19:30
I am really not aware what Proxy actually does or how it works. I would definitely check it! Though check the post again I made some updates!
– Evan
Nov 12 '18 at 19:30
If each IIFE is using its own part of the
config
, is there a reason why you wouldn't create each of the config objects under each IIFE?– Davion
Nov 12 '18 at 19:59
If each IIFE is using its own part of the
config
, is there a reason why you wouldn't create each of the config objects under each IIFE?– Davion
Nov 12 '18 at 19:59
So the concept of creating a separate module for just declaring variables is not a good idea as far as security and performance concerns?
– Evan
Nov 12 '18 at 21:55
So the concept of creating a separate module for just declaring variables is not a good idea as far as security and performance concerns?
– Evan
Nov 12 '18 at 21:55
Well, it's not really a question of performance in your specific case, it's just a matter of logic. If you have some configuration object that only one module is going to use, then you should create it locally under that module's scope, so no other can access it. It's a matter of basic scoping.
– Davion
Nov 12 '18 at 23:18
Well, it's not really a question of performance in your specific case, it's just a matter of logic. If you have some configuration object that only one module is going to use, then you should create it locally under that module's scope, so no other can access it. It's a matter of basic scoping.
– Davion
Nov 12 '18 at 23:18
thanks, @Davion. I am gonna make a little bit more research on this.
– Evan
Nov 13 '18 at 11:15
thanks, @Davion. I am gonna make a little bit more research on this.
– Evan
Nov 13 '18 at 11:15
add a comment |
IIFEs can only use Global
, Passed
, or internal variables. You can't make something available to a function scope that isn't available to a second function in the same scope.
Passing variables is one way, but perhaps the more practical way in certain circumstances would be to just nest your IIFEs as needed
const iife2 = (() => {
const iife1 = (() => {
const x = 10;
return x
})()
console.log(iife1);
/*iife2 scope*/
})()
const iife3 = (() => { /* HERE X CANNOT BE CALLED */ })()
add a comment |
IIFEs can only use Global
, Passed
, or internal variables. You can't make something available to a function scope that isn't available to a second function in the same scope.
Passing variables is one way, but perhaps the more practical way in certain circumstances would be to just nest your IIFEs as needed
const iife2 = (() => {
const iife1 = (() => {
const x = 10;
return x
})()
console.log(iife1);
/*iife2 scope*/
})()
const iife3 = (() => { /* HERE X CANNOT BE CALLED */ })()
add a comment |
IIFEs can only use Global
, Passed
, or internal variables. You can't make something available to a function scope that isn't available to a second function in the same scope.
Passing variables is one way, but perhaps the more practical way in certain circumstances would be to just nest your IIFEs as needed
const iife2 = (() => {
const iife1 = (() => {
const x = 10;
return x
})()
console.log(iife1);
/*iife2 scope*/
})()
const iife3 = (() => { /* HERE X CANNOT BE CALLED */ })()
IIFEs can only use Global
, Passed
, or internal variables. You can't make something available to a function scope that isn't available to a second function in the same scope.
Passing variables is one way, but perhaps the more practical way in certain circumstances would be to just nest your IIFEs as needed
const iife2 = (() => {
const iife1 = (() => {
const x = 10;
return x
})()
console.log(iife1);
/*iife2 scope*/
})()
const iife3 = (() => { /* HERE X CANNOT BE CALLED */ })()
const iife2 = (() => {
const iife1 = (() => {
const x = 10;
return x
})()
console.log(iife1);
/*iife2 scope*/
})()
const iife3 = (() => { /* HERE X CANNOT BE CALLED */ })()
const iife2 = (() => {
const iife1 = (() => {
const x = 10;
return x
})()
console.log(iife1);
/*iife2 scope*/
})()
const iife3 = (() => { /* HERE X CANNOT BE CALLED */ })()
answered Nov 12 '18 at 18:42
zfrisch
4,42811024
4,42811024
add a comment |
add a comment |
It is not necessary to use three IIFE, remember that as soon as your iife1
returns that value will be in the same scope of iife2
and iife3
thus you won't achieve your goal.
Your best bet is to declare iife2
and iife3
as normal functions and call them inside iife1
when some conditions are met and pass the variable that will create the scope of iife3
as argument.
this solution is more flexible and predictable than relying on the outer scope
const fn2 = function(x) {/* MAKE X AVAILABLE ONLY IN THIS FUNCTION */};
const fn3 = function() {/* HERE X CANNOT BE CALLED */};
(()=>{
const x = 10;
//your logic
fn2(x);
fn3();
})()
I don't thinkiife2
andiife3
are functions.
– Bergi
Nov 12 '18 at 18:45
1
you right, i've fixed the example
– Karim
Nov 12 '18 at 18:49
add a comment |
It is not necessary to use three IIFE, remember that as soon as your iife1
returns that value will be in the same scope of iife2
and iife3
thus you won't achieve your goal.
Your best bet is to declare iife2
and iife3
as normal functions and call them inside iife1
when some conditions are met and pass the variable that will create the scope of iife3
as argument.
this solution is more flexible and predictable than relying on the outer scope
const fn2 = function(x) {/* MAKE X AVAILABLE ONLY IN THIS FUNCTION */};
const fn3 = function() {/* HERE X CANNOT BE CALLED */};
(()=>{
const x = 10;
//your logic
fn2(x);
fn3();
})()
I don't thinkiife2
andiife3
are functions.
– Bergi
Nov 12 '18 at 18:45
1
you right, i've fixed the example
– Karim
Nov 12 '18 at 18:49
add a comment |
It is not necessary to use three IIFE, remember that as soon as your iife1
returns that value will be in the same scope of iife2
and iife3
thus you won't achieve your goal.
Your best bet is to declare iife2
and iife3
as normal functions and call them inside iife1
when some conditions are met and pass the variable that will create the scope of iife3
as argument.
this solution is more flexible and predictable than relying on the outer scope
const fn2 = function(x) {/* MAKE X AVAILABLE ONLY IN THIS FUNCTION */};
const fn3 = function() {/* HERE X CANNOT BE CALLED */};
(()=>{
const x = 10;
//your logic
fn2(x);
fn3();
})()
It is not necessary to use three IIFE, remember that as soon as your iife1
returns that value will be in the same scope of iife2
and iife3
thus you won't achieve your goal.
Your best bet is to declare iife2
and iife3
as normal functions and call them inside iife1
when some conditions are met and pass the variable that will create the scope of iife3
as argument.
this solution is more flexible and predictable than relying on the outer scope
const fn2 = function(x) {/* MAKE X AVAILABLE ONLY IN THIS FUNCTION */};
const fn3 = function() {/* HERE X CANNOT BE CALLED */};
(()=>{
const x = 10;
//your logic
fn2(x);
fn3();
})()
edited Nov 12 '18 at 18:49
answered Nov 12 '18 at 18:42
Karim
4,6341719
4,6341719
I don't thinkiife2
andiife3
are functions.
– Bergi
Nov 12 '18 at 18:45
1
you right, i've fixed the example
– Karim
Nov 12 '18 at 18:49
add a comment |
I don't thinkiife2
andiife3
are functions.
– Bergi
Nov 12 '18 at 18:45
1
you right, i've fixed the example
– Karim
Nov 12 '18 at 18:49
I don't think
iife2
and iife3
are functions.– Bergi
Nov 12 '18 at 18:45
I don't think
iife2
and iife3
are functions.– Bergi
Nov 12 '18 at 18:45
1
1
you right, i've fixed the example
– Karim
Nov 12 '18 at 18:49
you right, i've fixed the example
– Karim
Nov 12 '18 at 18:49
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53267949%2fmake-an-iife-return-variables-for-only-some-other-iifes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
meta.stackexchange.com/questions/66377/what-is-the-xy-problem
– Jonathan
Nov 12 '18 at 18:26
The IIFE doesn't know about anything, it just gets evaluated when assigning the value fo
const iife1
. You could (should?) equally have writtenconst iife1 = 10;
. (It's weird that you call this variable an "IIFE" though)– Bergi
Nov 12 '18 at 18:45