Yes, that's right. And in other cases, externs need to be treated similarly to classes added to the external-library-path, even if they are on the source-path.
-- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Mon, Jun 1, 2020 at 12:02 AM Alex Harui <aha...@adobe.com.invalid> wrote: > AIUI, in this particular case, externs should not have @export or > exportSymbol calls. The 'u' function is exportSymbol. > > Of course, I could be wrong, > -Alex > > On 5/31/20, 11:44 PM, "Yishay Weiss" <yishayj...@hotmail.com> wrote: > > Good, thanks. Out of curiosity, what special handling do externs need? > > From: Josh Tynjala<mailto:joshtynj...@bowlerhat.dev> > Sent: Monday, June 1, 2020 2:01 AM > To: Apache Royale Development<mailto:dev@royale.apache.org> > Subject: Re: Script Loading Order (Continuing Heads-Up thread from > Users) > > This appears to be related to my export/rename refactoring. As Alex > mentioned, externs need special handling, and I was treating them like > regular symbols. I should be able to get that fixed this week. > > -- > Josh Tynjala > Bowler Hat LLC < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev%2F&data=02%7C01%7Caharui%40adobe.com%7C161a52e6f1e743d8046a08d805f745e1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265906882631155&sdata=XaR6WYJSBgMUQfWQDc3wOD2TXSi1QqjpP1%2FcljV3IUc%3D&reserved=0 > > > > > On Sun, May 31, 2020 at 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&data=02%7C01%7Caharui%40adobe.com%7C161a52e6f1e743d8046a08d805f745e1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265906882631155&sdata=wkyh88Lwwhzu8%2BNcM6RMODIUfBF0vWlkFNUm6Mx8Wjs%3D&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&data=02%7C01%7Caharui%40adobe.com%7C161a52e6f1e743d8046a08d805f745e1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265906882631155&sdata=aOqz6hScb3UxeTWM3XJ%2FTerQnGc6B8QEuJgKR0eO9f8%3D&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&data=02%7C01%7Caharui%40adobe.com%7C161a52e6f1e743d8046a08d805f745e1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265906882641150&sdata=jRqEz2TAUdYDkRobaBUJHdAgxJ%2FajTNHNuaXyBhc0so%3D&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&data=02%7C01%7Caharui%40adobe.com%7C161a52e6f1e743d8046a08d805f745e1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265906882641150&sdata=jRqEz2TAUdYDkRobaBUJHdAgxJ%2FajTNHNuaXyBhc0so%3D&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&data=02%7C01%7Caharui%40adobe.com%7C161a52e6f1e743d8046a08d805f745e1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265906882641150&sdata=8%2F0ZUXlSGJfB8c1wW6a9qenM9CLzcFqBUe7GLYfCnxQ%3D&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&data=02%7C01%7Caharui%40adobe.com%7C161a52e6f1e743d8046a08d805f745e1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637265906882641150&sdata=79WbNRkoyomf6bCvL4TnduvU8vInlwya2QocLTGLV3E%3D&reserved=0 > > > > > > > > > > > > > > > > > > > >
