Express fragment dependencies? about tailor

[vigneshshanmugam]

If both the shell and foo fragments are synchronous then you don't need that require magic(def and undef) since the order of flushing them to the browser is guaranteed and requirejs takes care of the dependencies.

I did try out the scenario you have specified here and it works without any issues, It will also work if you have specified the foo.bundle.js from foo fragment Link Headers.

It will not work incase if the shell fragment is marked async.Please do provide an example repo if you still have any issues.

[jmaicher]

I though so as well, but I see two problems here:

1. require.js is fetching scripts with <script async>. So even if the fragments are synchronous, the order of the client-side fragment initialization [1] is not guaranteed, is it?

2. tailor is fetching scripts via require([script]), where script is the link provided in the fragment headers. So in order for other fragments to depend on that module, they must know the exact script URI upfront, which breaks encapsulation of fragments.

So the require magic, which is controlled by the shell fragment, defines a named shell module, very similar to how you at zalando do it in the header for react et al. provided by base assets [2]. Then, the depending fragments only need to know the module name, not the location: define('foo', ['shell'], () => {});.

[1] https://github.com/zalando/tailor/blob/master/src/pipe.js#L65
[2] Example from zalando

(function (d) {
    require(d);
    var arr = ['react', 'react-dom', /* ... */];
    while (i = arr.pop()) (function (dep) { define(dep, d, function (b) { return b[dep]; }) })(i);
}(['/base-assets/bundle.js']));

[vigneshshanmugam]

Regarding your concerns

1. Yes you are right here, require.js fetches the script via async so the order is not guaranteed. This is applicable only to scripts that are sent through link headers. If you want ordered behaviour you can use require.js onNodeCreated hook

require.config({
    onNodeCreated: function(node){
        node.async = false;
        node.defer = true;
    }
});

2. This was a conscious decision we took, We do not want fragment scripts to be dependent on another fragments. This also applied to scripts that are sent through link headers.

But in your case, since you are defining the shell fragment through fragment html

//shell fragment
http.createServer((req, res) => {
   res.end(`
      // whatever
       <script>
           define('shell', ['http://shell.com/shell'], () => {});
       <script>
  `)
}) 

If you do it via this way and if the other fragments like foo or whatever depends on this shell module, It wont break any behaviour since the fragments are loaded synchronously

[jmaicher]

Thanks for the reply.

Your last example is basically exactly how we solved it now, except that we also send the link header for http://shell.com/shell to let tailor load and initialize the fragment bundle regularly with the DOM element. Note that we also do not expose the init function from the bundle (default export) in the named shell module but only the named api export [1].

Generally I really like the decision to let fragments not depend on each other. In our case, the shell fragment is a special snowflake :-) but we still decided to serve it as a regular fragment. We probably stick with our solution for now, just wanted to know if there was already a proven solution to solve said problem.

From my side we can close the issue/question.

[1] https://gist.github.com/jmaicher/f696b510008adadd94d2b7fbb35c8966#file-2-shell-fragment-html-L9

[vigneshshanmugam]

Yes as you mentioned, tailor looks for default init module from the fragment scripts and it was a requirement.

Your solution will continue to work, But I would suggest you guys to put that script defining fragments to be in the head so that its loaded fast and user experience would be better.

Thanks. Feel free top open the issue if you have more questions :)