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%7Cd1f300255d7f46f3472808d7fc1aefad%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637255064930991098&sdata=LVleS2MHLv4Pjb9M5QcrsjkgxM00hstfuLdBrr8vCz0%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%7Cd1f300255d7f46f3472808d7fc1aefad%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637255064930991098&sdata=kvSg4mPijs4ZcZwXSObM12iY6r9iuDM%2F8YPlO9E%2FO7I%3D&reserved=0
