IOW, IIRC, dialogPolyFill is an extern and I don't think externs should be 
referenced like that, so I'm wondering if dialogPolyFill isn't being 
configured/picked up as an extern or we have a bug in what we output for 
externs.

HTH,
-Alex

On 5/31/20, 8:42 AM, "Alex Harui" <aha...@adobe.com.INVALID> wrote:

    I won't have time to set this up for a while.  What is the unminified JS 
for "u('dialogPolyfill',dialogPolyfill)"?
    
    -Alex
    
    On 5/31/20, 8:13 AM, "Yishay Weiss" <yishayj...@hotmail.com> wrote:
    
        Here’s the minimal test case I came up with for demonstrating the 
problem.
        
        <?xml version="1.0" encoding="utf-8"?>
        <js:Application 
xmlns:fx="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&amp;data=02%7C01%7Caharui%40adobe.com%7C23a0ae2fda4e44c8a55a08d805792eb1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265365333525875&amp;sdata=fT6D7lUCWbaaV4AvUdFQCiYJlVdFzNFDIWf0NigwLSI%3D&amp;reserved=0";
                        xmlns:js="library://ns.apache.org/royale/basic"
                        >
               <fx:Script>
                               <![CDATA[
                        private function dummy():void
                        {
                                        dialogPolyfill;
                        }
                               ]]>
               </fx:Script>
        </js:Application>
        
        Where dialogPolyfill is
        
        package
        {
                        /**
                        * @externs
                        */
                        COMPILE::JS
                        public class dialogPolyfill
                        {
                        /**
                 * <inject_script>
                 * var script = document.createElement("script");
                 * script.setAttribute("src", 
"https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdnjs.cloudflare.com%2Fajax%2Flibs%2Fdialog-polyfill%2F0.4.9%2Fdialog-polyfill.min.js&amp;data=02%7C01%7Caharui%40adobe.com%7C23a0ae2fda4e44c8a55a08d805792eb1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265365333525875&amp;sdata=o4W9MEMI8b%2FWHUSt5uPZbl39ZTuVCQOXLNVSqbwHDA8%3D&amp;reserved=0";);
                 * document.head.appendChild(script)
                 * </inject_script>
                        */
                                        public function dialogPolyfill(){}
                        }
        }
        
        In release I get a ‘ReferenceError: dialogPolyfill is not defined’
        
        u('dialogPolyfill',dialogPolyfill) of Examples.js, which is run before 
start()
        
        So in order to fix this scenario we would need Examples.js to wait for 
dialogPolyfill.min.js, not for start() to wait.
        
        From: Alex Harui<mailto:aha...@adobe.com.INVALID>
        Sent: Wednesday, May 20, 2020 8:09 PM
        To: dev@royale.apache.org<mailto:dev@royale.apache.org>
        Subject: Re: Script Loading Order (Continuing Heads-Up thread from 
Users)
        
        When I mentioned static initializers in my earlier post, it was about 
the timing of when some code would first access hljs.  Most externs will 
probably be first used from code that runs after application.start().  But if 
someone did:
        
        public static var HLJSClass:Class = hljs;
        
        Then that would fail before we can run application.start(), except that 
the compiler auto-converts static vars to lazy getters.
        
        However, the hljs usage is not wrapped, so there really aren't any 
static initializers to use, so it doesn’t matter if they are lazy or not.  I 
haven't looked at the other uses of inject_script, but if a class wraps the 
dependency, then it can implement its own waiting strategy unless the API has 
to be synchronous.  IOW, if I created a Highlighter class that used hljs 
internally, then if the "highlight" API returns a void, the wrapping 
implementation would load hljs.js and make the call when it is ready, which is 
essentially building in the façade you wrote.
        
        You could implement a map of injected scripts, but after thinking about 
it overnight, my first thought is to require that folks publish a var or uid as 
follows:
        
                 * <inject_script var="hljs_loaded">
                        * var scriptLoaded = function() { hljs_loaded = true) };
                        * var script = document.createElement("script");
                        * script.setAttribute("src", 
"https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdnjs.cloudflare.com%2Fajax%2Flibs%2Fhighlight.js%2F9.12.0%2Fhighlight.min.js&amp;data=02%7C01%7Caharui%40adobe.com%7C23a0ae2fda4e44c8a55a08d805792eb1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265365333535869&amp;sdata=NuO%2Fsmma%2Bw8cY3aq8ReC2MR8XgivCssSnolDnaMCbDk%3D&amp;reserved=0";);
                        * script.addEventListener("load", scriptLoaded);
                        * document.head.appendChild(script);
                    * </inject_script>
        
        Then the compiler may not need so much as a map, but can gather a list 
of variables to watch for in the setInterval before calling application.start();
        
        Of course, I could be wrong...
        -Alex
        
        On 5/20/20, 12:19 AM, "Yishay Weiss" <yishayj...@hotmail.com> wrote:
        
            Several questions/comments:
        
        
              1.  When you say static initializers should be lazy, do you mean 
load on the first lib api call? If so, wouldn’t that force async calls?
              2.  Do you have a way of using static initializers for externs 
files, which is how hljs was originally used?
              3.  To generate the script that waits for dynamically loaded 
scripts (I guess we don’t mind async css, though I’m not sure) we would need to 
have a map of injected scripts. So it looks like we’ll need to parse the 
injected_sctipt tag in any case.
        
            Thanks.
        
        
        
            From: Alex Harui<mailto:aha...@adobe.com.INVALID>
            Sent: Wednesday, May 20, 2020 9:52 AM
            To: dev@royale.apache.org<mailto:dev@royale.apache.org>
            Subject: Re: Script Loading Order (Continuing Heads-Up thread from 
Users)
        
            OK, I looked at the commit for hljs, and the code it replaced.  
AFAICT, that is an instantiation phase dependency and not a initialization 
phase dependency, so it should not matter if it loads before or after app.js 
(unless someone does use it in a non-lazy static initializer, which should be 
hard to do in Royale).  It should only matter that it is loaded before anybody 
calls it.  Other than static initializers, which should all be lazy, nobody 
should really call hljs until after the application.start() is called in the 
index.html.
        
            Here is the index.html for HelloWorld:
            <html>
            <head>
                    <meta http-equiv="X-UA-Compatible" 
content="IE=edge,chrome=1">
                    <meta http-equiv="Content-Type" content="text/html; 
charset=utf-8">
                    <link rel="stylesheet" type="text/css" 
href="HelloWorld.min.css">
                    <script type="text/javascript" 
src="./HelloWorld.js"></script>
            </head>
            <body>
                    <script type="text/javascript">
                            new HelloWorld().start();
                    </script>
            </body>
        
            IMO, for applications that use inject_script (modules will use the 
_deps file), we should generate code before the start() call that waits for any 
dynamic scripts to load.  So if HelloWorld needed hljs, the index.html would 
look more like:
        
            <head>
                    <meta http-equiv="X-UA-Compatible" 
content="IE=edge,chrome=1">
                    <meta http-equiv="Content-Type" content="text/html; 
charset=utf-8">
                    <link rel="stylesheet" type="text/css" 
href="HelloWorld.min.css">
                    <script type="text/javascript" 
src="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdnjs.cloudflare.com%2Fajax%2Flibs%2Fhighlight.js%2F9.12.0%2Fhighlight.min.js&amp;data=02%7C01%7Caharui%40adobe.com%7C23a0ae2fda4e44c8a55a08d805792eb1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265365333535869&amp;sdata=NuO%2Fsmma%2Bw8cY3aq8ReC2MR8XgivCssSnolDnaMCbDk%3D&amp;reserved=0";
                                    
onload="highlight.min.js.loaded=true;"></script>
                    <script type="text/javascript" 
src="./HelloWorld.js"></script>
            </head>
            <body>
                    <script type="text/javascript">
                            var appInterval = setInterval(function() { if 
(highlight.min.js.loaded) {
                                                                                
                                      clearInterval(appInterval);
                                                                                
                                      new HelloWorld().start();
                                                                                
                                }, 200);
                    </script>
            </body>
        
            Closure seems to use a hash of the URL instead of part of the URL 
to avoid collisions in case two different scripts are called main.js or 
something like that.  And there might be some better way than using 
setInterval, but the idea is to wait until the JS is loaded before calling 
start().
        
            HTH,
            -Alex
        
            On 5/19/20, 12:18 PM, "Yishay Weiss" <yishayj...@hotmail.com> wrote:
        
                See 99a8c8356573ff16b668f2d39a447355c673fee3
        
                Note that hljs is an externs file so I couldn’t implement 
static initializers there.
        
                There’s also a sort of a queue there for calls made before lib 
is loaded. I realize this doesn’t scale as a pattern, which is why I proposed 
to simplify annotations instead.
        
                It could be of course there’s a simpler solution I’m missing.
        
                From: Alex Harui<mailto:aha...@adobe.com.INVALID>
                Sent: Tuesday, May 19, 2020 10:03 PM
                To: dev@royale.apache.org<mailto:dev@royale.apache.org>
                Subject: Re: Script Loading Order (Continuing Heads-Up thread 
from Users)
        
                Yishay,
        
                I didn't think static initializers would require a façade or 
other fancy mechanism.  What kind of AS code ends up requiring this more 
complex solution?
        
                -Alex
        
                On 5/19/20, 10:34 AM, "Yishay Weiss" <yishayj...@hotmail.com> 
wrote:
        
                    Hi Carlos,
        
                    Sorry for not responding earlier, I missed this post.
        
                    I haven’t been able to replicate this in debug mode, so 
it’s interesting you’re seeing that.
        
                    I agree the façade solution is a bit cumbersome, but it 
works and maybe it’s worth having it out there as an example of using static 
initializers instead of injected code.
        
                    What do you think?
        
                    From: Carlos Rovira<mailto:carlosrov...@apache.org>
                    Sent: Monday, May 18, 2020 7:34 PM
                    To: Apache Royale Development<mailto:dev@royale.apache.org>
                    Subject: Re: Script Loading Order (Continuing Heads-Up 
thread from Users)
        
                    Hi Yishay,
        
                    I'm confused. The problem I reported was this;
        
                    ReferenceError: dialogPolyfill is not defined at
                    
/Users/carlosrovira/Dev/Royale/Source/royale-asjs/examples/jewel/TourDeJewel/target/javascript/bin/js-debug/App.js:10:1
        
                    And just as I'm copying here I'm seeing that while I'm 
running
                    "js-release", notice that the link refers to "js-debug", so 
I think there's
                    some wrong path involved here
        
                    I just updated with your latest change about hljs but I 
don't think we have
                    a problems with it. A part from that I don't like the 
solution to make a
                    Facade for a script, since that involves to create 2 
classes instead of
                    one. The solution should be just make 1 as3 file (instead 
of two) and that
                    have the proper inject reference.
        
                    Please can you revert the hljsFacade?
        
                    thanks
        
        
        
        
                    El lun., 18 may. 2020 a las 17:44, Yishay Weiss 
(<yishayj...@hotmail.com>)
                    escribió:
        
                    > Unless I missed something that’s what it’s doing right 
now after my fix.
                    > I’ll try to explain the scenario as I see it (no modules).
                    >
                    > Suppose we have an app that compiles to the following 
html.
                    >
                    > <html>
                    >                 <head>
                    >                                 <script 
type="text/javascript">
                    >                                                 var 
script =
                    > document.createElement("script");
                    >                                                 
script.setAttribute("src",
                    > "hljs.min.js");
                    >
                    > document.head.appendChild(script);
                    >                                 </script>
                    >                                 <script 
type=”text/JavaScript”
                    > src=”App.js”></script>
                    >                 </head>
                    >                 <body></body>
                    > </html>
                    >
                    > After the first script element is loaded, the dom will 
look like:
                    >
                    > <html>
                    >                 <head>
                    >                                 <script 
type="text/javascript">
                    >                                                 var 
script =
                    > document.createElement("script");
                    >                                                 
script.setAttribute("src",
                    > "hljs.min.js");
                    >
                    > document.head.appendChild(script);
                    >                                 </script>
                    >                                 <script 
type=”text/JavaScript”
                    > src=”hljs.min.js”></script>
                    >                                 <script 
type=”text/JavaScript”
                    > src=”App.js”></script>
                    >                 </head>
                    >                 <body></body>
                    > </html>
                    >
                    > However, App.js will still be loaded before hljs.min.js 
because it was not
                    > created dynamically. App.js will fail because it depends 
on hljs.
                    >
                    > From: Alex Harui<mailto:aha...@adobe.com.INVALID>
                    > Sent: Monday, May 18, 2020 6:21 PM
                    > To: dev@royale.apache.org<mailto:dev@royale.apache.org>
                    > Subject: Re: Script Loading Order (Continuing Heads-Up 
thread from Users)
                    >
                    > I don't think we have to inject these scripts into the 
main .js file.  The
                    > compiler knows when it is compiling the main app or a 
module.  When
                    > compiling the main app, it should inject the script in 
the HEAD of the html
                    > wrapper.  For modules, it can inject the script into a 
separate file.  The
                    > ModuleLoader already loads extra files before loading the 
module.  It can
                    > load one more file.
                    >
                    > Of course, I could be wrong...
                    > -Alex
                    >
                    > On 5/18/20, 7:38 AM, "Yishay Weiss" 
<yishayj...@hotmail.com> wrote:
                    >
                    >     From what I’ve read [1] scripts injected dynamically 
will always load
                    > after static script elements. So I don’t think there’s a 
good way to ensure
                    > the proper order in run-time unless we do something like
                    > 99a8c8356573ff16b668f2d39a447355c673fee3 , but that’s 
verbose and working
                    > with libs should be simple.
                    >
                    >     Any ideas?
                    >
                    >     [1]
                    > 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.html5rocks.com%2Fen%2Ftutorials%2Fspeed%2Fscript-loading%2F%23disqus_thread&amp;data=02%7C01%7Caharui%40adobe.com%7C23a0ae2fda4e44c8a55a08d805792eb1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265365333535869&amp;sdata=56kF%2Fof%2FpiXUO6c3N4vUok4aZHSHOvQI3%2FFwDnKx7E8%3D&amp;reserved=0
                    >
                    >     From: Alex Harui<mailto:aha...@adobe.com.INVALID>
                    >     Sent: Monday, May 18, 2020 8:03 AM
                    >     To: 
dev@royale.apache.org<mailto:dev@royale.apache.org>
                    >
                    >
                    >     Subject: Re: Script Loading Order (Continuing 
Heads-Up thread from
                    > Users)
                    >
                    >     Every time I look, closure seems to change how it 
works.  It looks
                    > like they are using callbacks and UIDs.  I assume they 
can't use await or
                    > Promise because of IE support.  I haven't looked at the 
code you generate,
                    > but might have to do something similar, IOW, wait for the 
callback or known
                    > value before continuing.
                    >
                    >     I think that if we create the script during the 
running of another
                    > script that we have to find a way to wait for that 
created script.
                    >
                    >     It might help to know what kind of initialization 
code needed the
                    > definition so early.  One alternative is that such code 
needs to be
                    > responsible for waiting.
                    >
                    >     Most of our Application classes have a wait 
mechanism.  We could
                    > leverage that, but that's also pretty late.
                    >
                    >     It could be that for Applications we generate the 
script in the head,
                    > and for modules we generate a separate script that is 
preloaded.
                    >
                    >     HTH,
                    >     -Alex
                    >
                    >     On 5/17/20, 9:03 AM, "Yishay Weiss" 
<yishayj...@hotmail.com> wrote:
                    >
                    >
                    >         >Is the script tag from inject_script going 
before or after the
                    > script tag for the application (should be before, >IMO)?
                    >
                    >         It’s going before but the network shows it’s 
loaded after.
                    >
                    >         >Make sure the script tag has the same settings 
as the script tags
                    > google closure uses in js-debug.  I think they set some 
options so the
                    > scripts load in order.
                    >
                    >         I see type being specified in the gcl script 
elements, while
                    > inject ones don’t. I suppose it’s worth seeing if that 
makes a difference,
                    > though I couldn’t find evidence for that on the web.
                    >
                    >
                    >
                    >
                    >
        
                    --
                    Carlos Rovira
                    
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C23a0ae2fda4e44c8a55a08d805792eb1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265365333535869&amp;sdata=BMRPAwlpASNFIqcO7jwZ1qFvbbNnu1vhxAy2dxZTpzg%3D&amp;reserved=0
        
        
        
        
        
        
        
        
    
    

Reply via email to