Dehydrated views are views that are structurally fixed, but their
directive instances and viewports are purged.
Support for local bindings is added to the view.
This is needed to allow view instantiation also in browsers that
don’t support the `<template>` element and because of this would
return elements from the content of `<template>` elements when
using `element.querySelectorAll`.
Also stores the `elementBinder.nestedProtoView` correctly
when a template directive was used on a `<template>` element.
This used to be valid code:
```
class Foo {
constructor() {
this.bar = ‘string’;
}
}
```
This will now fail since ‘bar’ is not explicitly
defined as a field. We now have to write:
```
class Foo {
bar:string; // << REQUIRED
constructor() {
this.bar = ‘string’;
}
}
```
The app is writen in ES6 and transpiles to ES5 and dart as part of the
usual build.
The app contains a component, a directive and a services wired together
through dependency injection.
Before Each:
- gulp build
For es5:
- gulp serve
- open 'localhost:8000/js/examples/lib/hello_world/'
For dart:
- gulp examples/pub.serve
- open 'localhost:8080'
Entry-point to bootstrapping is a rootComponent. The bootstrapping
method, uses the component's selector to find the insertion element in
the DOM, and attaches the component in its ShadowRoot.
Include shadowDom creation and integration tests for nested components.
Fix accidentally clobbered modules/core/test/compiler/view_spec.js by
previous commit.
- Allow to access containing component directive instance from the shadow DOM.
- Allow to access app services of the app level injector of the component
when the component is instantiated.
Supports:
- binds text nodes, element properties and directive properties
- locates decorator, component and template directives.
- inline templates of components
The compiler is built using a pipeline design,
see core/src/compiler/pipeline package.
Integration tests to show how the compiler, change_detection and DI work
together:
core/test/compiler/integration_spec.js
`pub get` is now only executed when the `pubspec.yaml` in the `modules`
folder is different than the `pubspec.yaml` in the `build/dart` folder.
Generates the file `build/dart/_analyzer.dart` that imports all modules
to run `dart analyzer` against all of them. The build will fail whenever
there are errors, warnings or hints in `dart analyzer`.
Changes the sources so that `dart analyzer` does not report any
error, warning or hint.
Closes#40
* remove `wraps` syntax enhancements for imports
and support new `import * as module from ...` syntax
- default imports are the wrong construct for importing
everything from a module
* moved tests from transpiler to jasmine and karma
- transpiler tests are included when running karma in main project folder
- transpiler is reloaded after every test run in karma,
so no need to restart karma when the transpiler has been changed.
- removed own gulp build for transpiler and `postinstall.sh`
as they are no more needed.
- transpiler tests are now executed in Dart AND JavaScript (used to be executed
only in Dart), which allowed to catch some bugs (see the bug with the
import specification above).
* made tests work in dart as well by using the following hack:
- dependencies are loaded from the `build` folder, which makes
running `gulp build` necessary before running karma for dart
- for this to work,
the dependencies are included in main `pubspec.yaml` of project
- reason for the hack: `karma-dart` loads all `packages` urls
directly from disc (should rather use the karma file list)
* added explicit annotations `FIELD`, `ABSTRACT`, ... to `facade/lang.*`
- needed for now that we can run tests and don't get errors for undefined
annotations.
* added `README.md` with details about the build and tests
Note: karma with dart is still not working
because of how `karma-dart` loads `package:…` dependencies.
Usage:
```
karma start karma-js.conf.js
karma start karma-dart.conf.js
```
Make sure to set `DARTIUM_BIN` env variable.
Refactors `js2dart`:
- live outside of the traceur module (`tools/js2dart/index.js`)
so it can be reused by gulp and karma
- automatically build the sources in memory,
so that `js2dart` can be used without running `gulp build` first
- provide a way to specify the moduleName of a compilation run
independently of the input filename. This helps error messages
and source maps (not yet enabled) to report the correct file name
Changes project setup:
- add module `test_lib` that contains the primitives for tests
(e.g. `describe`, `it`, …)
- clean up some sources that had errors in them
- module names in transpiled js and dart files don’t contain
`lib`, `test` nor `src` any more (e.g. `di/di`).
When chaining a `pubspec.yaml` we automatically run `pub get`.
In `gulp build` we also run `dartanalyzer` for all files
that have the pattern:
`<module>/lib/<module>.dart`
Closes#13Closes#5Closes#2