#LFA Modularization
###CSS
- We'll have to separate Stylus execution contexts even further, taking it from a
vendor
/user
unified model to a per-module model. This will certainly be much cleaner and faster, but it will have the downside of the userland not being able to override Stylus variables from the core or fromlfa-classroom
and vice-versa. We weren't doing this too much anyway and were overriding CSS rules instead, so I guess this is fine. This translates to the disappearance ofconfig.styl
. - This new level of separation can open the path to very easy support for other CSS precompilers (SASS, LESS, etc.)
###JS
- No more
require('lfa-classroom/view/NameView')
. Modules will have to explicitly export functionality.require('lfa-classroom').NameView
Again, this might actually be a tad cleaner. - Unavoidable dependency duplication, unless we explicitly specify a handful of commonly used libraries to go into a
vendor
bundle (jQuery, React, lodash). Realistically, we don't have that many shared dependencies across the whole project except forjquery
,lodash
,react
andbackbone
, so not a big problem, but a thing to look after.
###General
- Obviously, more network requests. Might actually not be that big of a problem, since smartly configured caching will help immensely here, especially when the user might be browsing multiple textbooks.
- Overall, it's definitely a much cleaner separation of concerns than what we have right now.
##Implementation
###JS
####Debug mode
As it is right now. One Webpack instance compiling everything in one bundle that also handles live reload. This will not enforce the nested require scenario (require('lfa-classroom/view/NameView')
), but we can't get proper live reload unless we use Webpack's application mode.
####Release mode
One Webpack compilation per module in library
mode and with libraryTarget
set to amd
. This way we'll get AMD modules with proper dependencies for each LFA module.
Then, use RequireJS to handle the async loading of the modules.
####Module separation
As plugins are now. Dispatcher and main app logic will still reside in lfa-core
. No need for a separate "lightweight core dispatcher", as it's still application logic and that can be neatly separated in different files. As a matter of fact, the bigger and fewer the LFA modules, the fewer requests we have.
The "lightweight core" will be made of just RequireJS and its configuration script. This way we cleanly separate module loading logic from application logic.
Also, move build-info
(previously SearchJSON
) into its own module, so it's separated from the app's core. This is the only place where we specify textbook-specific info, so this way we can have a reusable, separately hosted lfa-core
.
###CSS ###Debug mode Similar to what we have right now. Build a fake JS module that requires each CSS file with its appropriate loader.
###Release mode
Compile vendor
and main
into respective CSS files, then just drop the <link>
tags into <head>
.
##Difficulty: HARD
This will need a major revisiting of the compilation pipeline. ETA 1-1.5 weeks