| <!doctype html> | |
| <html> | |
| <head> | |
| <title>Jasmine Spec Runner</title> | |
| <link rel="stylesheet" href="../node_modules/jasmine-core/lib/jasmine-core/jasmine.css"> | |
| </head> | |
| <body> | |
| <script src="../node_modules/jasmine-core/lib/jasmine-core/jasmine.js"></script> | |
| <script src="../node_modules/jasmine-core/lib/jasmine-core/jasmine-html.js"></script> |
| wget https://yarnpkg.com/downloads/0.16.1/yarn-v0.16.1.tar.gz | |
| tar zvxf yarn-*.tar.gz | |
| dist/bin/yarn install |
| // Simplified config file | |
| const path = require('path'); | |
| const junitOutput = process.env.CIRCLE_TEST_REPORTS || 'junit' | |
| module.exports = function (config) { | |
| config.set({ | |
| port: 9876, | |
| logLevel: config.LOG_INFO, |
let is lazy, runs when it's invokedlet! are not lazy, runs immediately when the block is executedbefore blocks are also not lazy, has same precedence as let!For let! and before blocks, they execute based off source code order since it has the same precedence.
The first result will log undefined for the supposed deferred whereas the second will return the deferred. This is due to the resolution of the callback occurring before the assignment of the referenced variable happens. Note to reproduce this multiple times in console, a new variable will need to be used, otherwise it will seemingly pass because the deferred object already exists.
React.createClass.constructor associated with the stubbed instance can get messed up when not following the above advice.
| # Taken from https://github.com/naganowl/chaplin-mocha-grunt/blob/master/Gruntfile.coffee | |
| module.exports = (grunt) -> | |
| 'use strict' | |
| # For use as rename method in copy:assets. | |
| # Used to flatten the directory and place matched file in dest. | |
| flattenFile = (dest, src) -> | |
| if src.indexOf(@path) is 0 | |
| dest + src.slice @path.length | |
| else |
| module.exports = (grunt) -> | |
| # Load all grunt tasks matching the `grunt-*` pattern | |
| require('load-grunt-tasks')(grunt) | |
| grunt.initConfig | |
| pkg: grunt.file.readJSON 'package.json' | |
| # Only run tasks on modified files. | |
| watch: | |
| options: |
Typically a controller is able to keep a view around (rather than disposing and creating anew) a view via this.reuse('name', Constructor, opts), where opts is an object.
However, if opts differs from the previous time reuse is called (as dictated by _.isEqual which is what Composition.check calls under the hood), then the invocation will cause the view to be disposed and created from scratch.
Thus, in order for it to be used properly, the View options hash should not contain dynamic information as it will cause the view to always be re-created. An example where this may come up is a paginated view where the query params could be passed in so that the view can update parts of the itself to reflect the updated query (such as the current page number, search query, etc.).
Obviously (or not), this dynamic information should be stored on the model/collection and can be done via overriding/enhancing the update call (such as fetch) via re-declaration with appropriate logic (like creating a property o
grunt-mocha-blanket to pass LCOV info over (via https://github.com/alex-seville/blanket/blob/91528273af0fe495fdefd4ef8854d4a8a14ed56c/src/reporters/lcov_reporter.js#L27)