Thanks Josh, TDJ error now seems to be gone :) El mar., 2 jun. 2020 a las 9:13, Yishay Weiss (<yishayj...@hotmail.com>) escribió:
> Looks good, thanks. > > ________________________________ > From: Josh Tynjala <joshtynj...@bowlerhat.dev> > Sent: Monday, June 1, 2020 6:59:07 PM > To: Apache Royale Development <dev@royale.apache.org> > Subject: Re: Script Loading Order (Continuing Heads-Up thread from Users) > > Please give my latest royale-compiler commit a try. It should fix this > ReferenceError. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev> > > > 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="http://ns.adobe.com/mxml/2009" > > 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://cdnjs.cloudflare.com/ajax/libs/dialog-polyfill/0.4.9/dialog-polyfill.min.js > > "); > > * 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://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js > > "); > > * 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%7C5db4fc1f0ed844113a9d08d7fc8e131f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637255559454859456&sdata=hoREedwRG%2BXVsuvx5zymqNpNPH3FlptAyChhInwZ%2F6E%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%7C5db4fc1f0ed844113a9d08d7fc8e131f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637255559454869451&sdata=2EjRCIfbjT1okBPUCGBvDVvvv%2FYESige0uaJHppreo8%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%7C5db4fc1f0ed844113a9d08d7fc8e131f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637255559454869451&sdata=nuAIneqbkZeykwL3eG1ylsgJ9Xf%2FZXDSejyg4CJywhg%3D&reserved=0 > > > > > > > > > > > > > > > > > -- Carlos Rovira http://about.me/carlosrovira