jbrunton / core-js Goto Github PK

Consider using Jasmine.

Test coverage should be implemented across:

• module definitions
• event subscription
• extenders
• resources (incl. nested/extended objects)
• routing

Need to figure out how to incorporate with infrastructure project. Maybe tests should be written in core-js, but run together with js-infrastructure.

assuming a single entity makes unit testing awkward. it would be better to take a more OOP approach.

consider providing a constructor core.App, which may be instantiated as a single-instance variable (app.core) by the client application.

Continue breaking up into components - not convinced this is going to provide the perfect design, but it'll be more decoupled than now.

Related to jbrunton/core-js-blog-demo#6.

Ideally, you should be able to express precisely the associations you want to load, and the extensions to inject when assembling view models - eg,

new User().load(user_id, {
    extenders: { auditDates: { created: true, modified: true },
    includes: {
        recent_posts: {
            extenders: { auditDates: {} },
            includes: { tags: {} }
        },
        blogs: { extenders: { auditDates: {} } }
    }
});

To search blog posts by a specific tag,

Perhaps also a 'waiting' state after submitting data.

see the blog pages on demo app.

Global state is bad, and complicates testing. The mediator.js file should return a Mediator object constructor (instead of an object instance as it does now).

This will require changes (all in core-js) to:

• mediator.js, to return an object constructor.
• app.js (which, for now, just needs a new local variable to hold an instance of a Mediator).
• spec/MedatorSpec.js, to test the new object constructor.

To run the tests, open SpecRunner.html (in the core-js-blog-demo project) in a browser, and ensure they all pass (I think I commented out the ones which were failing..)

This is required for the syntax in issue #1, and also reduces the number of individual objects which have to be require'd.