Skip to content

Instantly share code, notes, and snippets.

@dapetcu21

dapetcu21/lfa-modularization.md

Last active August 29, 2015 14:23
Show Gist options
  • Save dapetcu21/4b1e05490582de55ef70 to your computer and use it in GitHub Desktop.
Save dapetcu21/4b1e05490582de55ef70 to your computer and use it in GitHub Desktop.
Download ZIP
LFA Modularization
Raw
lfa-modularization.md

#LFA Modularization

Impact

###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 from lfa-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 of config.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 for jquery, lodash, react and backbone, 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment