Make an IIFE return variables for only some other IIFES












0














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










share|improve this question




















  • 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 written const iife1 = 10;. (It's weird that you call this variable an "IIFE" though)
    – Bergi
    Nov 12 '18 at 18:45
















0














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










share|improve this question




















  • 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 written const iife1 = 10;. (It's weird that you call this variable an "IIFE" though)
    – Bergi
    Nov 12 '18 at 18:45














0












0








0







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










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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














  • 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 written const 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












3 Answers
3






active

oldest

votes


















0














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/






share|improve this answer





















  • 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










  • 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



















0














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 */ })()








share|improve this answer





























    0














    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();

    })()





    share|improve this answer























    • I don't think iife2 and iife3 are functions.
      – Bergi
      Nov 12 '18 at 18:45






    • 1




      you right, i've fixed the example
      – Karim
      Nov 12 '18 at 18:49











    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    0














    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/






    share|improve this answer





















    • 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










    • 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
















    0














    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/






    share|improve this answer





















    • 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










    • 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














    0












    0








    0






    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/






    share|improve this answer












    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/







    share|improve this answer












    share|improve this answer



    share|improve this answer










    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 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










    • 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










    • 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










    • 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













    0














    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 */ })()








    share|improve this answer


























      0














      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 */ })()








      share|improve this answer
























        0












        0








        0






        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 */ })()








        share|improve this answer












        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 */ })()






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 12 '18 at 18:42









        zfrisch

        4,42811024




        4,42811024























            0














            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();

            })()





            share|improve this answer























            • I don't think iife2 and iife3 are functions.
              – Bergi
              Nov 12 '18 at 18:45






            • 1




              you right, i've fixed the example
              – Karim
              Nov 12 '18 at 18:49
















            0














            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();

            })()





            share|improve this answer























            • I don't think iife2 and iife3 are functions.
              – Bergi
              Nov 12 '18 at 18:45






            • 1




              you right, i've fixed the example
              – Karim
              Nov 12 '18 at 18:49














            0












            0








            0






            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();

            })()





            share|improve this answer














            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();

            })()






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 12 '18 at 18:49

























            answered Nov 12 '18 at 18:42









            Karim

            4,6341719




            4,6341719












            • I don't think iife2 and iife3 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






            • 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


















            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Florida Star v. B. J. F.

            Danny Elfman

            Retrieve a Users Dashboard in Tumblr with R and TumblR. Oauth Issues