Continuing my monolouge ;-)
But I think I traced the issue to what's happening ... documented everything in
https://github.com/apache/royale-asjs/issues/899
So if I use autoLoad=true ... all modules sort of get loaded at the same time
(as the browser isn't mutli-threaded I would assume they are loaded
"first-come-first-served").
So what happens now is, that Royale asks to load the {moduleName}__deps.js file
... this contains information on where to get dependencies and what to
instantiate as content of the module.
So I guess roylae asks to load both module __deps.js files almost at the same
time and they are returned almost simultaneously.
When the application now processes the __deps.js file it builds the list of
dependency locations and then at the end executes the:
goog.require('JewelModule') line.
So the application checks if this type has been loaded yet, if not it checks
the dependenciesList if there is an entry for that type (which usually is the
first in the file).
This also lists dependencies of this type ... the same procedure happens:
Check, if loaded, if not add resources that we need to load. So in the end
there's a list of
Missing resources which we need to fetch from the server.
As soon as the browser is finished building this list and requesting stuff from
the server, the second modules __deps.js is returned and evaluated the same way.
The problem now is that the requested resources haven't been loaded yet, so the
first line of each of them hasn't been executed yet, which would register it.
So when building the list for the second module, the browser requests the code
for some types a second time. But as this is a different module, the URL for
the resources is different and the browser loads them a second time.
So as soon as the first set of resources are returned, they register themselves
and future modules would simply re-use them. But the time the second batch of
resources is processed I get the errors as they have already been registered
(with a different url ... which doesn't actually matter in this case).
So how do we avoid this problem? The probably trivial case would be to load the
modules one at a time and to have an internal queue to load the next module
after the first is finished.
I think that's sub-ideal.
Another option would be to not only track resources that have been loaded, but
also which ones have been requested and to use that instead.
In base.js (lines 692-717) this would probably have to happen, but that seems
to be closure code and not royale code :-/
So any thoughts on how we can fix this, as I do think it's an issue if really
doing cleanly separated modules.
Chris
Am 25.08.20, 11:04 schrieb "Christofer Dutz" <[email protected]>:
So I managed to whip up an example demonstrating the problem based on the
module loading example.
Created an issue and attached the project zip:
https://github.com/apache/royale-asjs/issues/899
Chris
Am 25.08.20, 09:03 schrieb "Christofer Dutz" <[email protected]>:
Hi all,
in a little discussion I had with Carlos this morning I think we got a
bit closer to solving my last issue ...
The problem is:
If you build application and modules in a single project, then all is
fine and the problems I am observing don't seem to apply (TourDeJewl)
However this setup is not really scalable for larger projects ...
projects with multiple teams.
If the modules are built in separate modules, the compiler really can't
know if a type has been declared before.
I mean ... I could use a type in two modules, but the compiler just
impossibly can know which module is loaded first (In my case the server tells
the client which modules to load after logging in)
I think the only way to fix this, is to perhaps change the way the
goog.addDependency entries are generated for modules.
I would propose to leave things the way they are for types of the
module itself, but change the way the dependencies of third party dependencies
are added.
So if a module uses a Royale Framework Type it would not generate a:
goog.addDependency but something like a goog.addDependencyIfUndeclared instead.
The difference would be that in this case it simply doesn't produce an
error if you try to define a type that already was defined.
I know this could be causing strange side-effects if you would build
some modules with different versions of dependencies, but I would just say: If
you do that ... you've deserved the problems you get ;-)
Chris
Am 24.08.20, 23:46 schrieb "Christofer Dutz"
<[email protected]>:
Hi all,
Thanks to Carlos' off-list tip I had another look at the
"module-output" compiler option.
From a look at the documentation it looked as if it would just copy
stuff somewhere else, but it actually does what I was doing with the replacer.
So I was able to clean up my configuration quite a bit, however
still when loading the duplicate classes I am getting errors.
I hope with this compiler option I'll be able to also use the
js-release versions ... will try that out asap.
Chris
Am 24.08.20, 22:08 schrieb "Christofer Dutz"
<[email protected]>:
Hi Carlos,
I had used your blog post to create my initial version ... but
I added your copy-resources solution to stage my test-code. Thanks for that.
But I also needed to replace the goog.addDependency urls in all
of the modules to use the relative path or my modules wouldn't load.
Now it's working, as I said yesterday, but if a module uses a
class that the main application also provides I get an error as soon as the
the module tries to add the already loaded type ... it doesn't
cause an error, but I get error reports in the developer-tools.
Chris
Am 24.08.20, 12:19 schrieb "Carlos Rovira"
<[email protected]>:
Hi Chris,
I solved that in blog example [1] via maven [2].
Maybe a hack similar to what you did?
Anyway I think I vaguely remember to see something related
to that in repo,
going to check and see if I find it and will come back.
I think this could be improved.
[1]
https://royale.apache.org/dividing-an-apache-royale-application-with-modules/
[2]
https://github.com/apache/royale-asjs/blob/fad51dad1cc77d27492dbf224233179da8483e36/examples/blog/BE0013_Dividing_an_Apache_Royale_application_with_modules/JewelModule/pom.xml#L48
El dom., 23 ago. 2020 a las 22:44, Christofer Dutz (<
[email protected]>) escribió:
> Ok ... so my replace plugin hack worked.
>
> Now I got the next little issue:
>
> - If a module declares a type which was declared
somewhere else, I am
> getting errors in the browser, however the application
still seems to work.
>
> Is there a way to tell the system to not fire errors if a
type was already
> declared?
>
> Chris
>
>
>
> Am 23.08.20, 22:04 schrieb "Christofer Dutz"
<[email protected]>:
>
> Ok ... so I got even further.
>
> If I modify the TestAModule__deps.js file and
replaced the "../../../"
> prefixes with "../../../main/TestAModule/".
> It seems to work ... so is there a way to have this
generated by the
> compiler?
>
> Otherwise I'll probably just have to use a replace
maven plugin to
> modify the files.
>
> Chris
>
>
> Am 23.08.20, 21:24 schrieb "Christofer Dutz" <
> [email protected]>:
>
> Ok ... so it seems to be picking up the
"TestAModule__deps.js"
> correctly ...
>
> However this tells the application to load stuff
from the root (No
> idea why all entries there have "../../../" as prefix.
But it seems all
> output files of Royale have this 3-segment prefix.
>
> Chris
>
>
> Am 23.08.20, 20:57 schrieb "Christofer Dutz" <
> [email protected]>:
>
> Hi all,
>
> today I extended my experiments to loading of
modules. So as
> soon as a user logs in, it gets a list of modules he’s
allowed to use.
> Then the application dynamically loads only
these modules.
>
> So I managed to get the ModuleLoader to
correctly load the css
> file from a subdirectory:
>
> <j:SectionContent name="TestAModule">
> <j:ModuleLoader height="100%" width="100%"
autoLoad="true"
> moduleName="TestAModule"
> modulePath="main/TestAModule"/>
> </j:SectionContent>
>
> In the browser I can see it loading some
stuff from the
> subdirectory “main/TestAModule” … unfortunately it tries
to load the js
> file “TestAModule.js” from the root and not from that
sub-directory.
>
> What do I have to do to make it load this
from the right place?
>
> Chris
>
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
