These are chat archives for systemjs/systemjs

28th
Dec 2014
Christian Theilemann
@geekflyer
Dec 28 2014 20:28
Hi there, is there a way to synchronously load a dependency on demand? e.g. System.importSync('./myModule') ?
Adam Stankiewicz
@sheerun
Dec 28 2014 20:33
On demand, probably no. If module is already loaded, then I think it was System.instantiate('./myModule')
Or you can use ES6 module syntax. It should properly translate imports calls.
Christian Theilemann
@geekflyer
Dec 28 2014 20:41
Hmm I unfortunately can't use ES6 module syntax or similar, since there's an expression in the import (dynamic) and the require or ES6 syntax doesn't allow for expressions in systemjs.
Looks like that at the moment (but is async):
System.import('../view/' + sViewName.split('.').pop() + '.view.xml!text',{name:module.id}).
With webpack that expression was possible :worried:
Christian Theilemann
@geekflyer
Dec 28 2014 20:56

when I attempt to use an expression in require I get the following error at runtime:
require('../view/' + sViewName.split('.').pop() + '.view.xml!text')

Uncaught TypeError: Module ../view/setupResult.view.xml!text not declared as a dependency.

Is there a way to explicitly register the dependencies in that directory or preload everything in that folder?
Adam Stankiewicz
@sheerun
Dec 28 2014 21:05
I wonder how webpack has no issues with it
How webpack knows what files to bundle when require is dynamic?
Christian Theilemann
@geekflyer
Dec 28 2014 21:08
in this particular example webpack will extract the information that I'm requesting a file in the directory view and that it ends with .view.xml . Then it will add all the files which match this pattern into a context bundle so that I can request them at runtime. It's described in detail here, and I can confirm it works: https://github.com/webpack/docs/wiki/context
Adam Stankiewicz
@sheerun
Dec 28 2014 21:12
Interesting. I have no idea whether System.js supports it. You probably need to wait for @guybedford
For now you probably need to add paths manually to System configuration
Christian Theilemann
@geekflyer
Dec 28 2014 21:36
ok, thanks. I'll try to hack around a bit in the meantime :-)
Guy Bedford
@guybedford
Dec 28 2014 22:15
Yes require expressions are not supported - you need to use System.import for "dynamic" requires of this form
We're working on a conditional system that can work at a static level
Using System.import does mean the interfaces of a module that need a module from it now need to be promise-based
sorry this is unrelated to conditional loading
I wonder if we can do something for wildcard requires, but yes at the moment everything is explicit
ideally you would just expand that require statement through a compiler into something more explicit
require('../view/' + sViewName.split('.').pop() + '.view.xml!text')
->
require('../view/first.view.xml!text')
require('../view/second.view.xml!text')
the point is that it is a compile-time operation
while SystemJS is all about bringing linking into runtime
that is - we can't know what files are available unless somehow compiled explicitly
certainly tooling could be made for that
Guy Bedford
@guybedford
Dec 28 2014 22:20
I suppose it would help to know where sViewName comes from in this exammple
Christian Theilemann
@geekflyer
Dec 28 2014 22:33
Ok, what I'm trying to do is to hack the Router of openui5 to load dependencies using systemjs by extending it's getView() function. https://github.com/SAP/openui5/blob/master/src/sap.ui.core/src/sap/ui/core/routing/Router.js#L235-L263
the normal router internally loads dependencies using jQuery.sap.require('path.to.class'), which makes a synchronous ajax call
During instantation of the Router one passes a configuration object to it, which contains the names of the Views to navigate to. When a route is matched the name gets passed to the getView(sViewName) function which I'm trying to overwrite. the getView() function is expected to return synchronous. Here's an example of the router config object: https://sapui5.hana.ondemand.com/sdk/#docs/guide/688f36bd758e4ce2b4e682eef4dc794e.html
Christian Theilemann
@geekflyer
Dec 28 2014 22:42
Would it be possible to offer a synchronous System.import variant in the future (which does a synchronous xhr request)? I know that's not very good practice, but for compatibility reasons / old apps it would be nice to make the switch.
Guy Bedford
@guybedford
Dec 28 2014 23:08
Right - routing needs to be an asynchronous operation
consider a large application where you want to load code on demand as you navigate it
this is where you use a dynamic System.import to load individualy pages through the router
then if it happens that the code is already in the loader registry, it is still a Promise operation and hence async on the next tick even then
ideally all modern routers are going towards asynchronous operation in this way
if you really need to hack something together though, you can try the following:
  • Manually keep a list of the page modules of your app
  • Bundle all those pages into one so you have a single page bundle
Perhaps this would look like:
app.js
require('page1');
require('page2');
require('page3');
followed by a bootstrap
then bundling app would bundle the pages
finally you can do
System.get('normalized/path/to/page1')
to get your synchronous access in the router
synchronous xhr is really not something that is possible, and will likely be deprecated in browsers of the future
Guy Bedford
@guybedford
Dec 28 2014 23:14
you can hack it in sure though
Christian Theilemann
@geekflyer
Dec 28 2014 23:32
ok
Adam Stankiewicz
@sheerun
Dec 28 2014 23:36
Why is parentParts derived from parentName and not parentAddress?
Guy Bedford
@guybedford
Dec 28 2014 23:37
name normalizes to name
moduleIDs are ID-relative, that's the space
next update will make all moduleIDs URLs
then it's equivalent to what you'd expect with normal URLs
Christian Theilemann
@geekflyer
Dec 28 2014 23:39
So I think I'll adapt the router a bit more to support async resource loading and use System.import then
Guy Bedford
@guybedford
Dec 28 2014 23:46
that would be the best practice certainly