g5-component.js v3

[gbabula]

g5-component.js v3

Updates and improvements for the next major release.

--

Core

• [x] Use Classes instead of prototypal inheritance (https://github.com/MajorLeagueBaseball/g5-component/pull/20)
• [x] Use native modules instead of CommonJS (https://github.com/MajorLeagueBaseball/g5-component/pull/20)
• [x] Improve debugging, allow for easier stack traces (#20 adds util.trace(...args))
• [ ] Move data extender to the Model
• [ ] Shared options for model and viewModel
• [x] Add options extender (#20 use the new DI model to extend options in the constructor)
• [ ] Clone data before emitting data event
• [ ] Simplify codebase where possible
• [ ] Overall cleanup and refactor

Build

• [x] Update directory structure (src/static/ --> dist/) (https://github.com/MajorLeagueBaseball/g5-component/pull/16)
• [x] Simplify NPM scripts (especially full/split builds) (#20 somewhat addresses this by using runtime dependency injection instead of static dependency bundles)
• [x] Remove jshint dependency in favor of eslint (#24)
• [x] Add esdoc dependency, generate documentation reference (#24)
• [x] Remove deprecated ghooks in favor of husky (#24)
• [x] Remove tape dependency in favor of mocha (#24)

Documentation

• [ ] Add architecture diagram (UML) to core-architecture.md
• [ ] Document all NPM scripts
• [ ] Document all baseline methods
• [x] Ensure all docs are up to date

Suggestions

• [x] Consider moving away from Browserify & Aliases (aliases: https://github.com/MajorLeagueBaseball/g5-component/pull/20)
• [x] Rename component/master #render
• [x] Reconsider inheritance of viewModel, model, etc... (#20)
• [x] Re-examine error catching and fallback of viewModel, model etc... (#20)
• [ ] Consider adding postcss and autoprefixer
• [x] Remove bower.json

Other

• [ ] Add additional examples

[kuhe]

@melissalabbe Was your suggestion to clone or to share options?

[melissalabbe]

I think shared options would solve the particular issue that we've come across. To summarize, we have found that there is often a need to validate and/or extend the options that are passed into the component. Here's a specific example in standings component to illustrate:

Options are validated and extended in the custom model: https://github.mlbam.net/fed-packages-components/fed-component-baseball-standings/blob/master/src/scripts/model/master.js#L32

Even though the custom viewModel has a reference to the options that were passed in to the component, it won't have the extended options from the model so we pass those back in: https://github.mlbam.net/fed-packages-components/fed-component-baseball-standings/blob/master/src/scripts/viewModel/master.js#L62

Since this extending/validating options is a common need it seems like there should be support for this in the component master. We shouldn't need a custom model to perform this step, and once the options are extended we'd ideally be able to access them in the model and viewModel.

[kuhe]

With the new DI model I'm proposing, you can modify the opts in the constructor like so:

class YourComponent extends G5Component {
    constructor(opts) {
        // Here do anything you need to opts, and build the DI container.
        super(opts, implementation);
    }
}

// Traditional factory function top level for your component.
export default function (opts) {
    return new YourComponent(opts);
}

The super(opts, implementation) call will still copy the opts unless we specifically remove that, but you make your modifications before that, they will at least propagate to all MVM/Event elements.