Skip to content
This repository has been archived by the owner on Dec 5, 2022. It is now read-only.

Express fragment dependencies? #121

Closed
jmaicher opened this issue Feb 5, 2017 · 5 comments
Closed

Express fragment dependencies? #121

jmaicher opened this issue Feb 5, 2017 · 5 comments

Comments

@jmaicher
Copy link

jmaicher commented Feb 5, 2017

We have a shell fragment (header + sidebar) and one or many content fragments (mostly a single SPA). Our plan for the shell is to provide certain services to the content fragments via a client-side JavaScript API (e.g. to interact with the sidebar menu or the header search). For that to work, we somehow need to express fragment dependencies or ensure otherwise that the shell bundle is evaluated before any content fragment bundle.

Currently, we implemented this through RequireJS by letting the shell fragment define an AMD module inside of the fragment template, which depends on the shell bundle that is resolved via tailor. I outlined the solution in a gist [1].

Is there any better way to achieve this?

[1] https://gist.github.com/jmaicher/f696b510008adadd94d2b7fbb35c8966

@vigneshshanmugam
Copy link
Collaborator

vigneshshanmugam commented Feb 6, 2017

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
Copy link
Author

jmaicher commented Feb 7, 2017

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
Copy link
Collaborator

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;
    }
});
  1. 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
Copy link
Author

jmaicher commented Feb 7, 2017

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
Copy link
Collaborator

vigneshshanmugam commented Feb 7, 2017

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 :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants