In a regular YUI App, the seed file is just the YUI Seed file, and by including it in your pages in a form of a script tag you are ready to use YUI, e.g.:
<script src="http://yui.yahooapis.com/3.7.3/build/yui/yui-min.js"></script>
From that url, the library can infer few things like the version of the library that should be used, the filter that you want to use (min, debug or raw), the CDN that is serving the library, etc. But when it comes to a mojito application, things are a little bit different, since the YUI library is bundle with the application using npm, and the way your application runs might also disrupt from a regular web application when it comes to mobile. On top of that, the introduction of a lot of new YUI modules, part of the mojito code, and part of the app code that should work in the same way that YUI Core modules work through the loader, all that makes it difficult to use the standard way for the seed in a mojito application.
Starting on Mojito 0.5.0, the seed files are fully controlled by the developer, and it does that through the regular application.json configuration, using the yui.config structure. Here is an example:
[
{
"settings": [ "master" ],
"yui": {
"config": {
"seed": [
"yui-base",
"loader-base",
"loader-yui3",
"loader-app",
"loader-app-base{langPath}"
]
}
}
}
]
In the example above, you can see how to redefine the seed file. It boils down to decide which YUI module should be part of the seed definition, and mojito will do the rest. The complex part is to decide what module is critical, in terms of performance, to become part of the seed file, and to understand what are the different modules that are available for mojito applications. In theory all YUI modules that are part of mojito core, YUI core, and your own application are available to be used as part of the seed, but on top of that, mojito generate few more files that are called synthetic modules. In the example above, the configuration that you see if the default configuration, where loader-app and loader-app-base{langPath} are synthetic files, the rest are just standard YUI Core modules.
This synthetic modules could be combined with regular modules from mojito, application and yui. Here is an example:
[
{
"settings": [ "master" ],
"yui": {
"config": {
"seed": [
"yui-base",
"loader-base",
"loader-yui3",
"loader-app",
"loader-app-base{langPath}",
"mojito-hb",
"FooBinderIndex",
"Foo"
]
}
}
}
]
Note: Our recommendation is to keep the seed size small, in any case, mojito will be able to load any required module at any given time, so, unless you have a strong reason for adding a new module to the seed array, try to keep it simple.
Every time you run mojito start or any alternative way to boot your application, the mojito store will analyze the folder structure and dependencies to try to understand the structure, and make assumptions in the way. Part of that analysis is to generate application metadata that could be used by YUI loader to load app and mojito modules on demand, and that part is critical for the application to function, and that's what those two synthetic module do. Aside from that, since your application could run in multiple languages when it comes to internationalization, you should not load all available language bundles in the client runtime for performance reasons, instead, you can load one based on the request information, and the user preferences. Each of those synthetic modules will be computed and will not represent physical files at all, so, when it comes to production, you might want to use Shaker to generate and bundle them as part of the content you want to upload to CDN, and when it comes to hybrid applications, those files will be generated into the build artifact as part of the mojito build command.
In terms of extending mojito functionalities, if you create a resource store addon, you can create new synthetic files, as well as control the seed generation by piping into store.yui.getAppSeedFiles method. Check the API documentation for more details on the signature of that method.
In mobile, and in some high performance applications, relying on the Loader to compute and resolve dependencies that are needed in a recursive way could affect booting time on the runtime drastically. For that, mojito is smart enough to use Y.Loader->resolve feature [http://yuilibrary.com/yui/docs/api/classes/Loader.html#method_resolve] to expand the loader metadata, which is considerable bigger than the regular metadata computed through loader-app-base{langPath}. Here is an example:
[
{
"settings": [ "master" ],
"yui": {
"config": {
"seed": [
"yui-base",
"loader-base",
"loader-yui3",
"loader-app",
"loader-app-resolved{langPath}"
]
}
}
}
]
This configuration is way more efficient in terms of CPU usages, which is specially useful when it comes to mobile devices. This new synthetic module is called loader-app-resolved{langPath}, and to activate it, just replace the loader-app-base{langPath} from the array of modules that compose the seed.
But that's not all, since that metadata is only the mojito core and application metadata. If you want to go the extra mile, you can do the same for YUI Core modules, and use another synthetic module that represents the expanded metadata of every YUI module required by your application. This is probably the most performant configuration that you can get today with mojito. Here is an example of it:
[
{
"settings": [ "master" ],
"yui": {
"config": {
"seed": [
"yui-base",
"loader-base",
"loader-yui3-resolved{langPath}",
"loader-app",
"loader-app-resolved{langPath}"
]
}
}
}
]
Note: Using loader-yui3-resolved{langPath} module restricts the domain of the YUI library to the set of YUI Core modules that are required by any mojito and application specific YUI module. In other words, if autocomplete-list is not required by a binder, controller, module or any other custom YUI module in your application, mojito will assume that autocomplete-list metadata is not really needed, and it will not include it in the resolved metadata to keep the size of the expanded metadata as small as possible. This is important if you have integration tests or functional tests that are meant to inject dynamic modules, and dependencies, or if you have custom Y.use statements that are not controlled by Mojito.