Socket
Socket
Sign inDemoInstall

aurelia-framework

Package Overview
Dependencies
10
Maintainers
1
Versions
58
Alerts
File Explorer

Advanced tools

Install Socket

Detect and block malicious and high-risk dependencies

Install

Comparing version 1.0.0-beta.1.0.5 to 1.0.0-beta.1.0.6

2

bower.json
{
"name": "aurelia-framework",
"version": "1.0.0-beta.1.0.5",
"version": "1.0.0-beta.1.0.6",
"description": "The aurelia framework brings together all the required core aurelia libraries into a ready-to-go application-building platform.",

@@ -5,0 +5,0 @@ "keywords": [

@@ -56,3 +56,3 @@ {

"name": "Loader",
"id": 605,
"id": 736,
"moduleName": "\"aurelia-loader\""

@@ -75,3 +75,3 @@ }

"name": "Container",
"id": 484,
"id": 208,
"moduleName": "\"aurelia-dependency-injection\""

@@ -122,3 +122,3 @@ }

"name": "Container",
"id": 484,
"id": 208,
"moduleName": "\"aurelia-dependency-injection\""

@@ -141,3 +141,3 @@ }

"name": "Loader",
"id": 605,
"id": 736,
"moduleName": "\"aurelia-loader\""

@@ -489,3 +489,3 @@ }

"name": "Container",
"id": 484,
"id": 208,
"moduleName": "\"aurelia-dependency-injection\""

@@ -492,0 +492,0 @@ }

@@ -13,3 +13,3 @@ ---

"translators": [],
"keywords": ["JavaScript", "SPA", "Setup"]
"keywords": ["JavaScript", "TypeScript", "SPA", "Setup"]
}

@@ -19,3 +19,3 @@ ---

Let's start by getting you set up with a great set of tools that you can use to build modern JavaScript applications. All our tooling is built on [Node.js](http://nodejs.org/). If you have that installed already, great! If not, you should go to [the official web site](http://nodejs.org/), download and install it. Everything else we need will be installed via Node's package manager ([npm](https://docs.npmjs.com/getting-started/what-is-npm)). If you already have npm installed, make sure you've got the [latest version](https://github.com/npm/npm/wiki/Troubleshooting#try-the-latest-stable-version-of-node) to avoid any issues with the other tools.
Let's start by getting you set up with a great set of tools that you can use to build modern ${context.language.name} applications. All our tooling is built on [Node.js](http://nodejs.org/). If you have that installed already, great! If not, you should go to [the official web site](http://nodejs.org/), download and install it. Everything else we need will be installed via Node's package manager ([npm](https://docs.npmjs.com/getting-started/what-is-npm)). If you already have npm installed, make sure you've got the [latest version](https://github.com/npm/npm/wiki/Troubleshooting#try-the-latest-stable-version-of-node) to avoid any issues with the other tools.

@@ -62,3 +62,3 @@ > Info

```
Everything we've done so far is standard Node.js build and package management procedures. It doesn't have anything specific to do with Aurelia itself. We're just walking you through setting up a modern JavaScript project and build configuration from scratch. You may be familiar with this already, but if not then welcome to this new and exciting world!
Everything we've done so far is standard Node.js build and package management procedures. It doesn't have anything specific to do with Aurelia itself. We're just walking you through setting up a modern ${context.language.name} project and build configuration from scratch. You may be familiar with this already, but if not then welcome to this new and exciting world!

@@ -70,3 +70,3 @@ > Info

If you've followed along this far, you now have all the libraries, build configuration and tools you need to create amazing JavaScript apps with Aurelia. The next thing to do is run the sample app. To see this in action, on your console, use the following command to build and launch the server:
If you've followed along this far, you now have all the libraries, build configuration and tools you need to create amazing ${context.language.name} apps with Aurelia. The next thing to do is run the sample app. To see this in action, on your console, use the following command to build and launch the server:
```shell

@@ -73,0 +73,0 @@ gulp watch

@@ -18,3 +18,3 @@ ---

Most platforms have a "main" or entry point for code execution. Aurelia is no different. If you've read the Getting Started Guide, then you've seen the `aurelia-app` attribute. Simply place this on an HTML element and Aurelia's bootstrapper will load an _app.js_ and _app.html_, databind them together and inject them into the DOM element on which you placed that attribute.
Most platforms have a "main" or entry point for code execution. Aurelia is no different. If you've read the Getting Started Guide, then you've seen the `aurelia-app` attribute. Simply place this on an HTML element and Aurelia's bootstrapper will load an _app${context.language.fileExtension}_ and _app.html_, databind them together and inject them into the DOM element on which you placed that attribute.

@@ -120,3 +120,3 @@ Often times you want to configure the framework or run some code prior to displaying anything to the user though. So chances are, as your project progresses, you will migrate towards needing some startup configuration. In order to do this, you can provide a value for the `aurelia-app` attribute that points to a configuration module. This module should export a single function named `configure`. Aurelia invokes your `configure` function, passing it the Aurelia object which you can then use to configure the framework yourself and decide what, when, and where to display your UI. Here's an example configuration file showing the standard configuration, the same configuration that is equivalent to what you would get when using `aurelia-app` without a value:

The root component is set by calling `aurelia.setRoot()`. If no values are provided, this defaults to treating the element with the `aurelia-app` attribute as the DOM host for your app and `app.js`/`app.html` as the source for the root component. However, you can specify whatever you want, just like this:
The root component is set by calling `aurelia.setRoot()`. If no values are provided, this defaults to treating the element with the `aurelia-app` attribute as the DOM host for your app and `app${context.language.fileExtension}`/`app.html` as the source for the root component. However, you can specify whatever you want, just like this:

@@ -146,3 +146,3 @@ <code-listing heading="Manual Root Component">

This causes the `my-root.js`/`my-root.html` to be loaded as the root component and injected into the `some-element` HTML element.
This causes the `my-root${context.language.fileExtension}`/`my-root.html` to be loaded as the root component and injected into the `some-element` HTML element.

@@ -242,5 +242,5 @@ ## [Bootstrapping Older Browsers](aurelia-doc://section/3/version/1.0.0)

To create a "feature", simply create a folder in your app; in the case of our example: `my-feature`. Inside that folder, place all the components and other code that pertain to that feature. Finally, create an `index.js` file at the root of the `my-feature` folder. The `index.js` file should export a single `configure` function. Here's what our code might look like for our hypothetical `my-feature` feature:
To create a "feature", simply create a folder in your app; in the case of our example: `my-feature`. Inside that folder, place all the components and other code that pertain to that feature. Finally, create an `index${context.language.fileExtension}` file at the root of the `my-feature` folder. The `index${context.language.fileExtension}` file should export a single `configure` function. Here's what our code might look like for our hypothetical `my-feature` feature:
<code-listing heading="A Feature Module (index)">
<code-listing heading="A Feature Module (index${context.language.fileExtension})">
<source-code lang="ES 2015/2016">

@@ -260,3 +260,3 @@ export function configure(config) {

The `configure` method receives an instance of the same `FrameworkConfiguration` object as the `aurelia.use` property. So, the feature can configure your app in any way it needs. An important note is that resources should be configured using paths relative to the `index.js` itself.
The `configure` method receives an instance of the same `FrameworkConfiguration` object as the `aurelia.use` property. So, the feature can configure your app in any way it needs. An important note is that resources should be configured using paths relative to the `index${context.language.fileExtension}` itself.

@@ -406,3 +406,3 @@ How then do we turn this feature on in our app? Here's an app configuration file that shows:

Aureia uses a _View Strategy_ to locate the view that is associated with a particular component's view-model. If the component doesn't specify its own view strategy, then Aurelia's `ViewLocator` service will use a fallback view strategy. The fallback strategy that is used is named `ConventionalViewStrategy`. This strategy uses the view-model's module id to conventionally map to its view id. For example, if the module id is "welcome.js" then this strategy will look for the view at "welcome.html". The conventional strategy's mapping logic can be changed if a different convention is desired. To do this, during bootstrap, import the `ViewLocator` and replace its `convertOriginToViewUrl` method with your own implementation. Here's some example code:
Aureia uses a _View Strategy_ to locate the view that is associated with a particular component's view-model. If the component doesn't specify its own view strategy, then Aurelia's `ViewLocator` service will use a fallback view strategy. The fallback strategy that is used is named `ConventionalViewStrategy`. This strategy uses the view-model's module id to conventionally map to its view id. For example, if the module id is "welcome${context.language.fileExtension}" then this strategy will look for the view at "welcome.html". The conventional strategy's mapping logic can be changed if a different convention is desired. To do this, during bootstrap, import the `ViewLocator` and replace its `convertOriginToViewUrl` method with your own implementation. Here's some example code:

@@ -409,0 +409,0 @@ <code-listing heading="Custom View Location Convention">

@@ -368,3 +368,3 @@ ---

> Warning
> Note that the order of running the tasks is important here. The `build` clears/removes all the files in `dist` folder. So, any bundle file in that folder will be deleted too. This is why we always have to run the `gulp bundle` after the `build` task is finished. If you are using `watch` you will have to be extra careful because every change you make in the source file will trigger a `build` task that clears the `dist` folder and any bundles as well.
> The order in which the tasks are run is important. The `build` removes all the files in `dist` folder. As a result, any bundle file in that folder will be deleted too. This is why we always have to run the `gulp bundle` after the `build` task is finished. If you are using `watch` you will have to be extra careful here. Every change you make in the source file will trigger a `build` task that clears the `dist` folder and any bundles as well.

@@ -371,0 +371,0 @@ Let's examine the configuration one property at a time:

@@ -24,3 +24,3 @@ ---

Many technologists make incorrect assumptions in this space. You may hear about "Google's Polymer" (or Angular) or "Facebook's React". However, these libraries aren't official products of their repsective companies. React team members have stated publicly that Facebook is not committed to the React library. Google developers have stated publicly that Polymer is not a Google product and developers are not considered customers. Angular and Polymer are two out of six UI libraries built by Google employees, all competitive with one another, and none officially recognized by the company. There is much marketing and brand recognition around these libraries but no guarantee and little hope of long-term stability. We encourage you to try to see past the marketing, brands and hype and into the core capabilities and benefits of the technology itself. If you do, we think you'll realize that Aurelia is the best option available.
Many technologists make incorrect assumptions in this space. You may hear about "Google's Polymer" (or Angular) or "Facebook's React". However, these libraries aren't official products of their respective companies. React team members have stated publicly that Facebook is not committed to the React library. Google developers have stated publicly that Polymer is not a Google product and developers are not considered customers. Angular and Polymer are two out of six UI libraries built by Google employees, all competitive with one another, and none officially recognized by the company. There is much marketing and brand recognition around these libraries but no guarantee and little hope of long-term stability. We encourage you to try to see past the marketing, brands and hype and into the core capabilities and benefits of the technology itself. If you do, we think you'll realize that Aurelia is the best option available.

@@ -27,0 +27,0 @@ ## [Commercial Products and Services](aurelia-doc://section/2/version/1.0.0)

@@ -146,3 +146,3 @@ ---

UI components consist of two parts: a view-model and a view. Simply create each part in its own file. Use the same file name but different file extensions for the two parts. For example: _hello.js_ and _hello.html_.
UI components consist of two parts: a view-model and a view. Simply create each part in its own file. Use the same file name but different file extensions for the two parts. For example: _hello${context.language.fileExtension}_ and _hello.html_.

@@ -387,3 +387,3 @@ <code-listing heading="Explicit Configuration">

* `.bind` - Users the default binding. One-way binding for everything but form controls, which use two-way binding.
* `.bind` - Uses the default binding. One-way binding for everything but form controls, which use two-way binding.
* `.one-way` - Flows data one direction: from the view-model to the view.

@@ -412,3 +412,3 @@ * `.two-way` - Flows data both ways: from view-model to view and from view to view-model.

> Info
> The `$event` property can be passed as an argument to a delegate/trigger function call if you need to access the event object.
> The `$event` value can be passed as an argument to a `delegate` or `trigger` function call if you need to access the event object.

@@ -597,8 +597,2 @@ <code-listing heading="Event Binding Examples">

> Danger
> Always use HTML sanitization. We provide a simple converter that can be used. You're encouraged to use a more complete html sanitizer such as [sanitize-html](https://www.npmjs.com/package/sanitize-html).
> Warning
> Binding using the `innerhtml` attribute simply sets the element's `innerHTML` property. The markup does not pass through Aurelia's templating system. Binding expressions and require elements will not be evaluated.
<code-listing heading="Binding innerHTML">

@@ -613,2 +607,8 @@ <source-code lang="HTML">

> Danger
> Always use HTML sanitization. We provide a simple converter that can be used. You are encouraged to use a more complete HTML sanitizer such as [sanitize-html](https://www.npmjs.com/package/sanitize-html).
> Warning
> Binding using the `innerhtml` attribute simply sets the element's `innerHTML` property. The markup does not pass through Aurelia's templating system. Binding expressions and require elements will not be evaluated.
<code-listing heading="Binding textContent">

@@ -796,5 +796,2 @@ <source-code lang="HTML">

> Info
> Like the `if` attribute, you can also use a `template` tag to group a collection of elements that don't have a parent element and place the `repeat` on the `template` element.
Contextual items availabe inside a repeat template:

@@ -808,2 +805,5 @@

> Info: Containerless Template Controllers
> The `if` and `repeat` attributes are usually placed on the HTML elements that they affect. However, you can also use a `template` tag to group a collection of elements that don't have a parent element and place the `if` or `repeat` on the `template` element instead.
<code-listing heading="Dynamically render UI into the DOM based on data.">

@@ -887,4 +887,4 @@ <source-code lang="HTML">

> Info
> A _Navigation Command_ is any object with a `navigate(router)` method. When one is encountered, the navigation will be cancelled and control will be passed to the navigation command. One navigation command is provided out of the box: `Redirect`.
> Info: Navigation Commands
> A _Navigation Command_ is any object with a `navigate(router: Router)` method. When a navigation command is encountered, the current navigation will be cancelled and control will be passed to the navigation command so it can determine the correct action. Aurelia provides one navigation command out of the box: `Redirect`.

@@ -1039,5 +1039,2 @@ The `params` object will have a property for each parameter of the route that was parsed, as well as a property for each query string value. `routeConfig` will be the original route configuration object that you set up. `routeConfig` will also have a new `navModel` property, which can be used to change the document title for data loaded by your view-model. For example:

> Warning
> Don't forget to configure your server appropriately.
<code-listing heading="Push State">

@@ -1076,2 +1073,5 @@ <source-code lang="ES 2015/2016">

> Warning
> PushState requires server-side support. Don't forget to configure your server appropriately.
### Reusing an existing VM

@@ -1521,4 +1521,4 @@

* `@inlineView(markup, dependencies?)` - Allows the developer to provide a string that will be compiled into the view.
* `@containerless()` - Causes the element's view to be rendered without the custom element container wrapping it. This cannot be used in conjunction with `@sync` or `@useShadowDOM`. It also cannot be uses with surrogate behaviors.
* `@useShadowDOM()` - Causes the view to be rendered in the ShadowDOM. When an element is rendered to ShadowDOM, a special `DOMBoundary` instance can optionally be injected into the constructor. This represents the shadow root.
* `@containerless()` - Causes the element's view to be rendered without the custom element container wrapping it. This cannot be used in conjunction with `@child`, `@children` or `@useShadowDOM` decorators. It also cannot be uses with surrogate behaviors. Use sparingly.

@@ -1525,0 +1525,0 @@ ### SVG Elements

@@ -18,7 +18,7 @@ ---

In Aurelia, user interface components are composed of _view_ and _view-model_ pairs. The view is written with HTML and is rendered into the DOM. The view-model is written with JavaScript and provides data and behavior to the view. The Templating Engine along with Dependency Injection are responsible for creating these pairs and enforcing a predictable lifecycle for the component. Once instantiated, Aurelia's powerful _databinding_ links the two pieces together allowing changes in your view-model to be reflected in the view and changes in your view to reflected in your view-model. This Separation of Concerns is great for developer/designer collaboration, maintainability, architectural flexibility, and even source control.
In Aurelia, user interface components are composed of _view_ and _view-model_ pairs. The view is written with HTML and is rendered into the DOM. The view-model is written with ${context.language.name} and provides data and behavior to the view. The Templating Engine along with Dependency Injection are responsible for creating these pairs and enforcing a predictable lifecycle for the component. Once instantiated, Aurelia's powerful _databinding_ links the two pieces together allowing changes in your view-model to be reflected in the view and changes in your view to reflected in your view-model. This Separation of Concerns is great for developer/designer collaboration, maintainability, architectural flexibility, and even source control.
To create a UI component, you need only create two files, one for each of the component parts. Let's create a simple "Hello" component. To do that we'll need a _hello.js_ for our view-model and _hello.html_ for our view. Here's the source for each:
To create a UI component, you need only create two files, one for each of the component parts. Let's create a simple "Hello" component. To do that we'll need a _hello${context.language.fileExtension}_ for our view-model and _hello.html_ for our view. Here's the source for each:
<code-listing heading="hello.js">
<code-listing heading="hello${context.language.fileExtension}">
<source-code lang="ES 2016">

@@ -90,3 +90,3 @@ export class Hello {

<code-listing heading="customer-detail.js">
<code-listing heading="customer-detail${context.language.fileExtension}">
<source-code lang="ES 2016">

@@ -93,0 +93,0 @@ import {inject} from 'aurelia-framework';

@@ -65,3 +65,3 @@ ---

When the bootstrapper loads it inspects the HTML document for _aurelia-app_ attributes. In this case it will find that the body has an `aurelia-app` attribute. This tells the bootstrapper to load our _app_ view-model and its view, conventionally located in _app.js_ and _app.html_ and then compose them as an Aurelia application in the DOM.
When the bootstrapper loads it inspects the HTML document for _aurelia-app_ attributes. In this case it will find that the body has an `aurelia-app` attribute. This tells the bootstrapper to load our _app_ view-model and its view, conventionally located in _app${context.language.fileExtension}_ and _app.html_ and then compose them as an Aurelia application in the DOM.

@@ -72,9 +72,9 @@ Wait a minute....we don't have an _app_ view-model or view. Ummm...WHAT NOW!?

In Aurelia, user interface components have two parts: a _view_ and a _view-model_. The _view_ is written with HTML and is rendered into the DOM. The _view-model_ is written with JavaScript/TypeScript and provides data and behavior to the _view_. Aurelia's powerful _databinding_ links the two pieces together allowing changes in your data to be reflected in the _view_ and vice versa. This Separation of Concerns is great for developer/designer collaboration, maintainability, architectural flexibility and even source control.
In Aurelia, user interface components have two parts: a _view_ and a _view-model_. The _view_ is written with HTML and is rendered into the DOM. The _view-model_ is written with ${context.language.name} and provides data and behavior to the _view_. Aurelia's powerful _databinding_ links the two pieces together allowing changes in your data to be reflected in the _view_ and vice versa. This Separation of Concerns is great for developer/designer collaboration, maintainability, architectural flexibility and even source control.
Let's see how it works...
In the _src_ folder find the _app.html_ and _app.js_ files. This is the app component's view and view-model, the files that the bootstrapper is loading. Let's start by replacing the _view-model_ with a simple class to hold a _firstName_ and _lastName_. We'll also add a computed property for _fullName_ and a method to "submit" the person. Here's what your _app.js_ file should look like after you have made the changes:
In the _src_ folder find the _app.html_ and _app${context.language.fileExtension}_ files. This is the app component's view and view-model, the files that the bootstrapper is loading. Let's start by replacing the _view-model_ with a simple class to hold a _firstName_ and _lastName_. We'll also add a computed property for _fullName_ and a method to "submit" the person. Here's what your _app${context.language.fileExtension}_ file should look like after you have made the changes:
<code-listing heading="app.js">
<code-listing heading="app${context.language.fileExtension}">
<source-code lang="ES 2015">

@@ -163,3 +163,3 @@ export class Welcome {

> Info
> Info: Binding Commands
> The `.bind` command uses the default binding behavior for any property. The default is one-way binding (model to view) for everything except form controls, which default to two-way. You can always override this by using the explicit binding commands `.one-way`, `.two-way` and `.one-time`. Similarly, you can use `.delegate` for event delegation in place of `.trigger`.

@@ -169,5 +169,5 @@

A one page app isn't very interesting. We should probably add some more screens and set up a client-side router, don't you think? Let's begin by renaming our _app.js_ and _app.html_ to _welcome.js_ and _welcome.html_ respectively. This will be the first screen of our multi-screen app. Now, lets create a new _app.js_ and _app.html_ which will serve as our "layout", "master page" or "root component". The view will contain our navigation UI and the content placeholder for the current screen and the view-model will configure a router instance with our routes. We'll start with the view-model so you can see how to set up the router:
A one page app isn't very interesting. We should probably add some more screens and set up a client-side router, don't you think? Let's begin by renaming our _app${context.language.fileExtension}_ and _app.html_ to _welcome${context.language.fileExtension}_ and _welcome.html_ respectively. This will be the first screen of our multi-screen app. Now, lets create a new _app${context.language.fileExtension}_ and _app.html_ which will serve as our "layout", "master page" or "root component". The view will contain our navigation UI and the content placeholder for the current screen and the view-model will configure a router instance with our routes. We'll start with the view-model so you can see how to set up the router:
<code-listing heading="app.js">
<code-listing heading="app${context.language.fileExtension}">
<source-code lang="ES 2015/2016">

@@ -257,3 +257,4 @@ export class App {

> **Note:** The `navigation` property on the router is an array populated with all the routes you marked as `nav:true` in your route config. Aurelia models its `repeat.for` syntax after the new standard ES2015 `for..of` loop. So, you can think of looping over the array of navigable routes and generating UI for each.
> Info
> The `navigation` property on the router is an array populated with all the routes you marked as `nav:true` in your route config. Aurelia models its `repeat.for` syntax after the new standard ES2015 `for..of` loop. So, you can think of looping over the array of navigable routes and generating UI for each.

@@ -272,3 +273,3 @@ Also on the `li` you can see a demonstration of how to use string interpolation to dynamically add/remove classes. Further down in the view, there's a second `ul`. See the binding on its single child `li`? `if.bind="router.isNavigating"` This conditionally adds/removes the `li` based on the value of the bound expression. Conveniently, the router will update its `isNavigating` property whenever it is....navigating.

<code-listing heading="app.js (updated)">
<code-listing heading="app${context.language.fileExtension} (updated)">
<source-code lang="ES 2015/2016">

@@ -306,5 +307,5 @@ export class App {

If you guessed that we need to create a _users.js_ and _users.html_ file, you are correct. Here's the source:
If you guessed that we need to create a _users${context.language.fileExtension}_ and _users.html_ file, you are correct. Here's the source:
<code-listing heading="users.js">
<code-listing heading="users${context.language.fileExtension}">
<source-code lang="ES 2015">

@@ -403,3 +404,3 @@ import {HttpClient} from 'aurelia-fetch-client';

> Info
> Info: Navigation Lifecycle Hooks
> The full navigation lifecycle includes `canActivate`, `activate`, `canDeactivate` and `deactivate` hooks. The can* methods can return a boolean (or Promise of boolean) to accept or reject the transition into or out of the current screen.

@@ -410,3 +411,3 @@

<source-code heading="users.html">
<code-listing heading="users.html">
<source-code lang="HTML">

@@ -433,11 +434,9 @@ <template>

</source-code>
</source-code>
</code-listing>
The view for this screen is pretty straight forward. There's nothing you haven't seen before.
The view for this screen is pretty straight forward. There's nothing you haven't seen before. Once you've got all this in place, go ahead and run your app again. You should now see two items in the nav bar and be able to switch back and forth between them. Huzzah!
Once you've got all this in place, go ahead and run your app again. You should now see two items in the nav bar and be able to switch back and forth between them. Huzzah!
Let's recap. To add a page to your app:
1. Add the route configuration to the _app.js_ router.
1. Add the route configuration to the _app${context.language.fileExtension}_ router.
2. Add a view-model.

@@ -469,5 +468,5 @@ 3. Add a view with the same name (but with an .html extension).

Guess what? Our simple view-model/view conventions still apply for custom elements. Let's create a _nav-bar.js_ and a _nav-bar.html_. Here's the code for the view-model first:
Guess what? Our simple view-model/view conventions still apply for custom elements. Let's create a _nav-bar${context.language.fileExtension}_ and a _nav-bar.html_. Here's the code for the view-model first:
<code-listing heading="nav-bar.js">
<code-listing heading="nav-bar${context.language.fileExtension}">
<source-code lang="ES 2015">

@@ -536,9 +535,9 @@ import {bindable, decorators} from 'aurelia-framework';

This looks almost identical to the navbar HTML in our original _app.html_ file. We've basically extracted that and put it into this template. Instead of binding to _app.js_ though, it's now binding to _nav-bar.js_.
This looks almost identical to the navbar HTML in our original _app.html_ file. We've basically extracted that and put it into this template. Instead of binding to _app${context.language.fileExtension}_ though, it's now binding to _nav-bar${context.language.fileExtension}_.
This is a very simple custom element with no real behavior, but it is complete and usable as shown above.
Wait! I know what you are thinking. This custom element is so simple...it seems a bit silly to require a JavaScript class just to define the single `router` property. Couldn't we get rid of that somehow? Well, the answer is YES. For very simple elements which have no behavior but simply provide a view that can be bound to a set of properties, we can omit the JavaScript file altogether. Let's see how that works.
Wait! I know what you are thinking. This custom element is so simple...it seems a bit silly to require a ${context.language.name} class just to define the single `router` property. Couldn't we get rid of that somehow? Well, the answer is YES. For very simple elements which have no behavior but simply provide a view that can be bound to a set of properties, we can omit the ${context.language.name} file altogether. Let's see how that works.
First, delete the _nav-bar.js_ file. Next, we need to make one change to the _nav-bar.html_ file. On the template element, we can declare the bindable properties of our element like this:
First, delete the _nav-bar${context.language.fileExtension}_ file. Next, we need to make one change to the _nav-bar.html_ file. On the template element, we can declare the bindable properties of our element like this:

@@ -571,4 +570,4 @@ <code-listing heading="nav-bar.html">

> Info
> Anything required into a view with the `require` element is local to the view. As a result, you don't have to worry about name conflicts. You can also load app-wide elements and other behaviors for convenience so you don't have to require common resources in every view.
> Info: View Encapsulation
> Anything required into a view with the `require` element has visibility only inside that view. As a result, you don't have to worry about name conflicts between various view resources. For convenience, you can also load app-wide elements and other behaviors during your application's bootstrapping phase.

@@ -583,5 +582,5 @@ You may wonder how Aurelia determines the name of the custom element. By convention, it will use the export name of the class, lowered and hyphenated. In our html-only scenario, it will use the file name.

First, let's update our _app.js_ with the new configuration. Here's what it should look like:
First, let's update our _app${context.language.fileExtension}_ with the new configuration. Here's what it should look like:
<code-listing heading="app.js (updated...again)">
<code-listing heading="app${context.language.fileExtension} (updated...again)">
<source-code lang="ES 2015/2016">

@@ -621,5 +620,5 @@ export class App {

Nothing new there. The interesting part is what's inside _child-router.js_...
Nothing new there. The interesting part is what's inside _child-router${context.language.fileExtension}_...
<code-listing heading="child-router.js">
<code-listing heading="child-router${context.language.fileExtension}">
<source-code lang="ES 2016">

@@ -626,0 +625,0 @@ export class ChildRouter {

@@ -20,2 +20,3 @@ ---

* Forward compatible with JavaScript technology that is 2-3 years in the future.
* Full support for TypeScript.

@@ -22,0 +23,0 @@ ## [Modern DOM](aurelia-doc://section/2/version/1.0.0)

@@ -37,3 +37,4 @@ ---

* **Integrates Well with Others** - Because of the extensible design of Aurelia and a number of core technical considerations we made early on, it's easy to integrate Aurelia with any 3rd party library or framework. For example, you can easily integrate with jQuery, React, Polymer, Bootstrap, MaterializeCSS and much more.
* **TypeScript Support** - Each Aurelia library is released with its own d.ts files. We also have official TypeScript beginner kits and production quality starter kits.
* **An Official Product with Commercial Support** - Libraries like Angular, Polymer and React are neither official products of their associated companies nor is any official support or commitment to the library by the company guaranteed. However, Aurelia is an official product of Durandal Inc., has commercial and enterprise support available and we are committed to it over the long haul. If your are building core technology for your business, you want to know that your technology provider is as committed as you are. Aurelia is a clear choice.
* **Thriving Community and Ecosystem** - With one of the largest and most active developer gitter channels in the JavaScript world, a huge number of contributors and a large active core team, Aurelia has an amazing community. Our ecosystem also includes video training resources, books in production, master class opportunities, upcoming conferences, component libraries, tooling, an official partner network and more. Aurelia has been used to build just about every type of application and is used by large, well-known multi-national companies and enterprises.

@@ -0,1 +1,6 @@

### 1.0.0-beta.1.0.6 (2015-12-22)
* docs update
## 1.0.0-beta.1.0.3 (2015-12-03)

@@ -2,0 +7,0 @@

{
"name": "aurelia-framework",
"version": "1.0.0-beta.1.0.5",
"version": "1.0.0-beta.1.0.6",
"description": "The aurelia framework brings together all the required core aurelia libraries into a ready-to-go application-building platform.",

@@ -5,0 +5,0 @@ "keywords": [

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc