IMO, we want to avoid overuse of this feature such that we should not need
specifying order. There should be very few places where this is truly needed.
It is tempting to use it for other things, but it really should only be used
when the initialization of the class and prototype requires it.
What would be a scenario where a PNG or SVG file is required to initialize a
class?
We will probably be better off not parsing anything as part of this feature.
Just copy stuff into a known place. If that requires the developer to write
both an html and js version, that still may be simpler than dealing with
parsing issues.
And again, without knowing the circumstances for why DialogPolyFill was
required, we don't know that we are trying to solve an edge case that we don't
really need to solve. If we're requiring folks to write injection directives
it might be easier to tell them to rewrite some initialization pattern in a
lazy way.
My 2 cents,
-Alex
On 5/19/20, 9:23 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> @inject_script path/to/script.js
> @inject_styles path/to/styles.css
+1 to this (or something along the lines).
While we’re at it, some way to specify order of files would be in order.
We really need a full solution of including (i.e. png,svg) files as well.
> On May 19, 2020, at 7:19 PM, Josh Tynjala <joshtynj...@bowlerhat.dev>
wrote:
>
> I'm not a fan of this syntax. It's a weird mix between HTML/XML and...
some
> kind of flat configuration file?
>
> I'd rather use a separate <inject_script> for each JS file and a separate
> <inject_styles> for each CSS file.
>
> Or maybe something like this:
>
> @inject_script path/to/script.js
> @inject_styles path/to/styles.css
>
> --
> Josh Tynjala
> Bowler Hat LLC
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev%2F&data=02%7C01%7Caharui%40adobe.com%7Ca1a4a474384a481640d208d7fc10ff72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637255022261904839&sdata=7eXHLu4D3W4opNUO6NXtfymsvUkuXHzsBLpjNZbUwY4%3D&reserved=0>
>
>
> On Tue, May 19, 2020 at 12:22 AM Yishay Weiss <yishayj...@hotmail.com>
> wrote:
>
>> I propose to change the syntax to
>>
>> <inject_sources>
>>
js=https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjs1.js%2F&data=02%7C01%7Caharui%40adobe.com%7Ca1a4a474384a481640d208d7fc10ff72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637255022261904839&sdata=QP181by1EjNrfTgAVQ0qsbaTtFhEN3Bp4ik9nvyTf2A%3D&reserved=0
>>
js=https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjs2.js%2F&data=02%7C01%7Caharui%40adobe.com%7Ca1a4a474384a481640d208d7fc10ff72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637255022261904839&sdata=tSEf4Ly4%2BceB7pakD%2B6NZivSZswdCJOe72CCrG9JY8Y%3D&reserved=0
>>
css=https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcss1.js%2F&data=02%7C01%7Caharui%40adobe.com%7Ca1a4a474384a481640d208d7fc10ff72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637255022261904839&sdata=sDT97lo77XqeiW2flaY%2BHcHNTiKh8nSiYhyg0wgX0f4%3D&reserved=0
>> <inject_sources>
>>
>> If it’s in the main app the compiler will parse this and inject html,
same
>> way it did before. Injected html is ensured to load serially, so it
should
>> load before App.js.
>>
>> If it’s in a module the compiler will parse this and inject a script to
>> the __deps file we create for modules, similar to what’s being done now.
It
>> may be that we’ll need to add to the script some mechanism to ensure
serial
>> loading, similar to what gcl does.
>>
>> I can explore this when I have more time, probably next week, or someone
>> else is welcome to fix this differently.
>>
>> Thanks.
>>
>>
>>
>> From: Alex Harui<mailto:aha...@adobe.com.INVALID>
>> Sent: Monday, May 18, 2020 7:53 PM
>> To: dev@royale.apache.org<mailto:dev@royale.apache.org>
>> Subject: Re: Script Loading Order (Continuing Heads-Up thread from Users)
>>
>> Ah, ok. I thought that closure was injecting the main app's script block
>> so the dynamic script would be in front of it but it makes sense that
>> wouldn't happen at release time.
>>
>> IIRC, we control the launch of the app. I thought there is one more
>> script somewhere that calls app.start() that is generated by the
compiler.
>> IMO, that script can be altered to wait for scripts to load.
>>
>> HTH,
>> -Alex
>>
>>
>> On 5/18/20, 8:44 AM, "Yishay Weiss" <yishayj...@hotmail.com> wrote:
>>
>> 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%7Ca1a4a474384a481640d208d7fc10ff72%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637255022261904839&sdata=fW6MMmTf3afTeHbntw%2BdKpNHEfUTUcpPKyMO8DpsUck%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.
>>
>>
>>
>>
>>
>>
>>
