mirror of
https://github.com/namibia/awesome-cheatsheets.git
synced 2024-11-16 18:15:19 +00:00
744 lines
24 KiB
JavaScript
744 lines
24 KiB
JavaScript
/*
|
|
* -----------------------
|
|
* Ember.js Cheatsheet
|
|
* -----------------------
|
|
*
|
|
* Docs: https://guides.emberjs.com/
|
|
* Quick start: https://guides.emberjs.com/current/getting-started/quick-start/
|
|
*
|
|
* Table of contents
|
|
* -------------------
|
|
* 01 | Installation
|
|
* 02 | Ember CLI
|
|
* 03 | Directory layout
|
|
* 04 | Routes
|
|
* 05 | Templates
|
|
* 06 | Components
|
|
* 07 | Models
|
|
* 08 | Services
|
|
* 09 | Testing
|
|
* 10 | Addons
|
|
* 11 | Configuration
|
|
* 12 | Community
|
|
*
|
|
*/
|
|
|
|
/*
|
|
* 01 | Installation
|
|
* --------------------------------------------------------------
|
|
* Getting started with Ember is easy. Ember projects are created
|
|
* and managed through our command line build tool Ember CLI.
|
|
*/
|
|
|
|
```
|
|
npm install -g ember-cli
|
|
ember new <application-name>
|
|
ember serve
|
|
```
|
|
|
|
|
|
|
|
/*
|
|
* 02 | Ember CLI
|
|
* --------------------------------------------------------------
|
|
* Ember CLI is the Ember.js command line utility that provides a
|
|
* fast Broccoli-powered asset pipeline, a strong conventional
|
|
* project structure, and a powerful addon system for extension.
|
|
*
|
|
* Among the principal features of Ember CLI are:
|
|
- Project/Addon creation: create new projects quickly without having to worry about project structure;
|
|
- Build pipeline: asset compilation, finger-printing and more out of the box;
|
|
- Generators: use the built-in generators and get files that follow the latest practices, and matching tests;
|
|
- Ember Addons: extend both your application and Ember CLI itself with community solutions. Also an excellent
|
|
way to easily integrate 3rd party libraries into your Ember app.
|
|
*/
|
|
|
|
Basic commands
|
|
|
|
Command | Aliases | Description
|
|
--------------------------------------------------
|
|
```
|
|
ember new | | Create new project with the provided name (ex. ember new <app-name>)
|
|
ember server | ember s | Starts development server (default port is 4200)
|
|
ember test | ember t | Run tests in CI mode
|
|
ember generate | ember g | Run generator
|
|
ember destroy | ember d | Remove code created by generator
|
|
ember help | ember h | Get more info on available cli command
|
|
ember install | ember i | Install given addon into project and save to package.json
|
|
ember | | List available cli commands
|
|
```
|
|
|
|
Useful commands
|
|
```
|
|
ember s --proxy <proxy-url>
|
|
ember s --port <port>
|
|
```
|
|
|
|
|
|
|
|
/*
|
|
* 03 | Directory Layout
|
|
* --------------------------------------------------------------
|
|
*
|
|
* Layout of the root folder */
|
|
|
|
app/
|
|
` This is where folders and files for models, components, routes, templates and styles are stored. The majority of your coding on an Ember project happens in this folder. `
|
|
config/
|
|
` The config directory contains the environment.js where you can configure settings for your app. `
|
|
node_modules/
|
|
` This directory is from npm. npm is the package manager for Node.js. Ember is built with Node and uses a variety of Node.js modules for operation. The package.json file maintains the list of current npm dependencies for the app. Any Ember CLI addons you install will also show up here. `
|
|
public/
|
|
` This directory contains assets such as images and fonts. `
|
|
vendor/
|
|
` This directory is where front-end dependencies (such as JavaScript or CSS) that are not managed by NPM go. `
|
|
tests/testem.js
|
|
` Automated tests for our app go in the tests folder, and Ember CLI's test runner testem is configured in testem.js. `
|
|
ember-cli-build.js
|
|
` This file describes how Ember CLI should build our app. `
|
|
package.json
|
|
` Packages listed in package.json are installed in the node_modules directory. `
|
|
|
|
/*
|
|
* Layout of the app directory */
|
|
adapters/
|
|
` Adapters with the convention adapter-name.js. `
|
|
components/
|
|
` Components with the convention component-name.js. Components must have a dash in their name. So blog-post is an acceptable name, but post is not. `
|
|
controllers/
|
|
` Controllers behave like a specialized type of Component that is rendered by the router when entering a Route. `
|
|
helpers/
|
|
` Helpers with the convention helper-name.js. Helpers must have a dash in their name. Remember that you must register your helpers by exporting makeBoundHelper or calling registerBoundHelper explicitly. `
|
|
models/
|
|
` Models with the convention model-name.js. `
|
|
routes/
|
|
` Routes with the convention route-name.js. Child routes are defined in sub-directories, parent/child.js. To provide a custom implementation for generated routes (equivalent to App.Route when using globals), use app/routes/basic.js. `
|
|
styles/
|
|
` Contains your stylesheets, whether SASS, LESS, Stylus, Compass, or plain CSS (though only one type is allowed, see Asset Compilation). These are all compiled into <app-name>.css. `
|
|
templates/
|
|
` Your HTMLBars templates. These are compiled to /dist/assets/<app-name>.js. The templates are named the same as their filename, minus the extension (i.e. templates/foo/bar.hbs -> foo/bar). `
|
|
serializers/
|
|
` Serializers for your models or adapter, where model-name.js or adapter-name.js. `
|
|
utils/
|
|
` Utility modules with the convention utility-name.js. `
|
|
router.js
|
|
` Your route configuration. The routes defined here correspond to routes in app/routes/. `
|
|
|
|
|
|
/*
|
|
* 03 | Routes
|
|
* --------------------------------------------------------------
|
|
*
|
|
* When your application starts, the router matches the current URL to the routes that you've defined.
|
|
* The routes, in turn, are responsible for displaying templates, loading data, and setting up application state.
|
|
*
|
|
* > ember g route <route-name>
|
|
*/
|
|
|
|
import Route from '@ember/routing/route';
|
|
|
|
export default Route.extend({
|
|
model() {
|
|
// Typically, the model hook should return an Ember Data record,
|
|
// but it can also return any promise object (Ember Data records are
|
|
// promises), or a plain JavaScript object or array. Ember will wait
|
|
// until the data finishes loading (until the promise is resolved)
|
|
// before rendering the template.
|
|
}
|
|
});
|
|
|
|
|
|
|
|
/*
|
|
* 04 | Templates
|
|
* --------------------------------------------------------------
|
|
*
|
|
* Ember uses the Handlebars templating library to power your app's user
|
|
* interface. Handlebars templates contain static HTML and dynamic
|
|
* content inside Handlebars expressions, which are invoked with
|
|
* double curly braces: {{}}.
|
|
*
|
|
* Templates are backed with a context. A context is an object from
|
|
* which Handlebars expressions read their properties. In Ember this
|
|
* is often a component. For templates rendered by a route (like application.hbs),
|
|
* the context is a controller.
|
|
*
|
|
* > ember g template <template-name>
|
|
*/
|
|
|
|
|
|
// Here's an basic exmpale of a template
|
|
```hbs
|
|
Hello, <strong>{{firstName}} {{lastName}}</strong>!
|
|
```
|
|
|
|
|
|
|
|
/*
|
|
* 05 | Components
|
|
* --------------------------------------------------------------
|
|
*
|
|
* Ember components are used to encapsulate markup and style into
|
|
* reusable content. Components consist of two parts: a JavaScript
|
|
* component file that defines behavior, and its accompanying Handlebars
|
|
* template that defines the markup for the component's UI.
|
|
*
|
|
* > ember g component <component-name>
|
|
*/
|
|
|
|
// app/components/<component-name>.js
|
|
import Component from '@ember/component';
|
|
|
|
export default Component.extend({
|
|
});
|
|
|
|
// app/templates/components/<component-name>.hbs
|
|
```hbs
|
|
{{yield}}
|
|
```
|
|
|
|
/*
|
|
* Actions
|
|
*
|
|
* Provide a means to communicate events and changes
|
|
*/
|
|
|
|
// app/components/rental-listing.js
|
|
import Component from '@ember/component';
|
|
|
|
export default Component.extend({
|
|
|
|
isWide: false,
|
|
|
|
actions: {
|
|
toggleImageSize() {
|
|
this.toggleProperty('isWide');
|
|
}
|
|
}
|
|
|
|
});
|
|
|
|
// Actions can be attached to DOM elements inside templates using the {{action}} helper
|
|
``` app/templates/components/rental-listing.hbs
|
|
<article class="listing">
|
|
<a {{action 'toggleImageSize'}} class="image {{if isWide "wide"}}">
|
|
<img src="http://www.fillmurray.com/200/300" alt="">
|
|
</a>
|
|
</article>
|
|
```
|
|
|
|
/*
|
|
* Component lifecycle
|
|
*
|
|
* As components are rendered, re-rendered and finally removed, Ember provides
|
|
* lifecycle hooks that allow you to run code at specific times in a component's life.
|
|
*/
|
|
|
|
On Initial Render
|
|
1 init
|
|
2 didReceiveAttrs
|
|
3 willRender
|
|
4 didInsertElement // Good place to integrate with 3rd party libraries
|
|
5 didRender
|
|
|
|
On Re-Render
|
|
1 didUpdateAttrs
|
|
2 didReceiveAttrs
|
|
3 willUpdate
|
|
4 willRender
|
|
5 didUpdate
|
|
6 didRender
|
|
|
|
On Component Destroy
|
|
1 willDestroyElement
|
|
2 willClearRender
|
|
2 didDestroyElement
|
|
|
|
|
|
/*
|
|
* Block params
|
|
*
|
|
* Components can have properties passed in, but they can also return
|
|
* output to be used in a block expression.
|
|
*/
|
|
|
|
// Here an entire blog post model is being passed to the component as a
|
|
// single component property. In turn the component is returning values using yield.
|
|
|
|
``` app/templates/index.hbs
|
|
{{blog-post post=model}}
|
|
```
|
|
|
|
``` app/templates/components/blog-post.hbs
|
|
{{yield post.title post.body post.author}}
|
|
```
|
|
|
|
// The block expression can then use block params to bind names to any yielded
|
|
// values for use in the block. This allows for template customization when using
|
|
// a component, where the markup is provided by the consuming template, but any
|
|
// event handling behavior implemented in the component is retained such as click() handlers.
|
|
|
|
``` app/templates/index.hbs
|
|
{{#blog-post post=model as |title body author|}}
|
|
<h2>{{title}}</h2>
|
|
<p class="author">by {{author}}</p>
|
|
<p class="post-body">{{body}}</p>
|
|
{{/blog-post}}
|
|
```
|
|
// The names are bound in the order that they are passed to yield in the component template.
|
|
|
|
|
|
|
|
/*
|
|
* 06 | Models
|
|
* --------------------------------------------------------------
|
|
*
|
|
* Models are objects that represent the underlying data that your application
|
|
* presents to the user. Different apps will have very different models,
|
|
* depending on what problems they're trying to solve.
|
|
*
|
|
* Ember Data, included by default when you create a new application,
|
|
* is a library that integrates tightly with Ember to make it easy to
|
|
* retrieve models from your server as JSON, save updates back to the server,
|
|
* and create new models in the browser.
|
|
*
|
|
* > ember g model <model-name>
|
|
*/
|
|
|
|
import DS from 'ember-data';
|
|
import { computed } from '@ember/object';
|
|
|
|
const { attr, Model } = DS;
|
|
|
|
export default Model.extend({
|
|
|
|
firstName: attr('string'),
|
|
lastName: attr('string'),
|
|
birthday: attr('date'),
|
|
|
|
|
|
// Computed properties
|
|
// These are effectively fuctions declared as properties. The function's result
|
|
// will recompute every time one of the provided 'dependent keys' changes.
|
|
|
|
fullName: computed('firstName', 'lastName', function() {
|
|
let firstName = this.get('firstName');
|
|
let lastName = this.get('lastName');
|
|
|
|
return `${firstName} ${lastName}`;
|
|
})
|
|
|
|
});
|
|
|
|
|
|
|
|
/*
|
|
* 07 | Services
|
|
* --------------------------------------------------------------
|
|
*
|
|
* A Service is an Ember object that lives for the duration of the application, and can
|
|
* be made available in different parts of your application. Services are useful for
|
|
* features that require shared state or persistent connections.
|
|
*
|
|
* Example uses of services might include:
|
|
*
|
|
* - User/session authentication.
|
|
* - Geolocation.
|
|
* - WebSockets.
|
|
* - Server-sent events or notifications.
|
|
* - Server-backed API calls that may not fit Ember Data.
|
|
* - Third-party APIs.
|
|
* - Logging.
|
|
*
|
|
* > ember g service <service-name>
|
|
*/
|
|
|
|
|
|
/*
|
|
* Defining services
|
|
*
|
|
* Like any Ember object, a service is initialized and can have properties and
|
|
* methods of its own. Below, the shopping cart service manages an items array
|
|
* that represents the items currently in the shopping cart.
|
|
*/
|
|
|
|
// app/services/shopping-cart.js
|
|
import Service from '@ember/service';
|
|
|
|
export default Service.extend({
|
|
items: null,
|
|
|
|
init() {
|
|
this._super(...arguments);
|
|
this.set('items', []);
|
|
},
|
|
|
|
remove(item) {
|
|
this.get('items').removeObject(item);
|
|
}
|
|
});
|
|
|
|
/*
|
|
* Accessing services
|
|
*
|
|
* To access a service, you can inject it in any object such as a component or another
|
|
* service using the `inject` function from the `@ember/service` module.
|
|
*/
|
|
|
|
// app/components/cart-contents.js
|
|
import Component from '@ember/component';
|
|
import { inject } from '@ember/service';
|
|
|
|
export default Component.extend({
|
|
|
|
shoppingCart: inject() // will load the service in file /app/services/shopping-cart.js
|
|
|
|
actions: {
|
|
remove(item) {
|
|
this.get('shoppingCart').remove(item);
|
|
}
|
|
}
|
|
});
|
|
|
|
// Once injected into a component, a service can also be used in the template.
|
|
// Note cart being used below to get data from the cart.
|
|
```hbs app/templates/components/cart-contents.hbs
|
|
<ul>
|
|
{{#each cart.items as |item|}}
|
|
<li>
|
|
{{item.name}}
|
|
<button {{action "remove" item}}>Remove</button>
|
|
</li>
|
|
{{/each}}
|
|
</ul>
|
|
```
|
|
|
|
|
|
|
|
/*
|
|
* 08 | Testing
|
|
* --------------------------------------------------------------
|
|
*
|
|
* Testing is a core part of the Ember framework and its development cycle.
|
|
*
|
|
* > ember g acceptance-test <test-name>
|
|
* > ember g integration-test <test-name>
|
|
* > ember g unit-test <test-name>
|
|
* > ember t --server
|
|
* > ember s && visit localhost:4200/tests
|
|
*/
|
|
|
|
/*
|
|
* Acceptance & application tests
|
|
*
|
|
* In these kinds of tests, we interact with the application in the same ways that a
|
|
* user would, such as filling out form fields and clicking buttons. Application
|
|
* tests ensure that the interactions within a project are basically functional, the
|
|
* core features of a project have not regressed, and the project's goals are being met.
|
|
*
|
|
* Some useful helpers from '@ember/test-helpers':
|
|
* - `click(selector)`
|
|
* Clicks an element and triggers any actions triggered by the element's click event and
|
|
* returns a promise that fulfills when all resulting async behavior is complete.
|
|
*
|
|
* - `fillIn(selector, value)`
|
|
* Fills in the selected input with the given value and returns a promise that
|
|
* fulfills when all resulting async behavior is complete. Works with <select> elements
|
|
* as well as <input> elements. Keep in mind that with <select> elements, value must be set
|
|
* to the value of the <option> tag, rather than its content (for example, true rather than "Yes").
|
|
*
|
|
* - `triggerKeyEvent(selector, type, keyCode)`
|
|
* Simulates a key event type, e.g. keypress, keydown, keyup with the desired keyCode on element found by the selector.
|
|
*
|
|
* - `triggerEvent(selector, type, options)`
|
|
* Triggers the given event, e.g. blur, dblclick on the element identified by the provided selector.
|
|
*
|
|
* - `visit(url)`
|
|
* Visits the given route and returns a promise that fulfills when all resulting async behavior is complete.
|
|
*
|
|
* - `currentURL()`
|
|
* Returns the current URL.
|
|
*
|
|
* - `find(selector, context)`
|
|
* Finds an element within the app's root element and within the context (optional). Scoping to the
|
|
* root element is especially useful to avoid conflicts with the test framework's reporter, and this
|
|
* is done by default if the context is not specified.
|
|
*
|
|
* - `findAll(selector)`
|
|
* Find all elements matched by the given selector. Equivalent to calling querySelectorAll() on the
|
|
* test root element. Returns an array of matched elements.
|
|
*
|
|
*/
|
|
|
|
import { module, test } from 'qunit';
|
|
import { setupApplicationTest } from 'ember-qunit';
|
|
import { visit, fillIn, click } from '@ember/test-helpers';
|
|
|
|
module('Acceptance | posts', function(hooks) {
|
|
|
|
// `setupApplicationTest` deals with application setup and teardown.
|
|
setupApplicationTest(hooks);
|
|
|
|
test('should add new post', async function(assert) {
|
|
await visit('/posts/new');
|
|
await fillIn('input.title', 'My new post');
|
|
await click('button.submit');
|
|
|
|
const title = this.element.querySelector('ul.posts li:first').textContent;
|
|
assert.equal(title, 'My new post');
|
|
});
|
|
});
|
|
|
|
/*
|
|
* Integration & rendering tests
|
|
*
|
|
* Rendering Tests are, as the name suggests, rendering components and helpers
|
|
* by verifying the correct behaviour when the component or helper interacts
|
|
* with the system in the same way that it will within the context of the application,
|
|
* including being rendered from a template and receiving Ember's lifecycle hooks.
|
|
*
|
|
* If we need to test the interactions between various parts of the application,
|
|
* such as behaviour between UI controls we can utilize Rendering Tests.
|
|
*/
|
|
|
|
// app/components/pretty-color.js
|
|
import Component from '@ember/component';
|
|
import { computed } from '@ember/object';
|
|
|
|
export default Component.extend({
|
|
attributeBindings: ['style'],
|
|
|
|
style: computed('name', function() {
|
|
const name = this.get('name');
|
|
return `color: ${name}`;
|
|
})
|
|
});
|
|
|
|
// tests/integration/components/pretty-color-test.js
|
|
import { module, test } from 'qunit';
|
|
import { setupRenderingTest } from 'ember-qunit';
|
|
import { render } from '@ember/test-helpers';
|
|
import hbs from 'htmlbars-inline-precompile';
|
|
|
|
module('Integration | Component | pretty color', function(hooks) {
|
|
|
|
// Make sure to call the setupRenderingTest function together with the hooks
|
|
// parameter first in your new module. This will do the necessary setup for
|
|
// testing your component for you, including setting up a way to access the
|
|
// rendered DOM of your component later on in the test, and cleaning up
|
|
// once your tests in this module are finished.
|
|
setupRenderingTest(hooks);
|
|
|
|
test('it renders', async function(assert) {
|
|
assert.expect(2);
|
|
|
|
// set the outer context to red
|
|
this.set('colorValue', 'red');
|
|
|
|
await render(hbs`{{pretty-color name=colorValue}}`);
|
|
|
|
assert.equal(this.element.querySelector('div').getAttribute('style'), 'color: red', 'starts as red');
|
|
|
|
this.set('colorValue', 'blue');
|
|
|
|
assert.equal(this.element.querySelector('div').getAttribute('style'), 'color: blue', 'updates to blue'); });
|
|
});
|
|
|
|
|
|
// Stubbing services
|
|
//
|
|
// In cases where components have dependencies on Ember services, it is
|
|
// possible to stub these dependencies for rendering tests. You stub Ember
|
|
// services by using the built-in register() function to register your
|
|
// stub service in place of the default.
|
|
|
|
import { module, test } from 'qunit';
|
|
import { setupRenderingTest } from 'ember-qunit';
|
|
import { render } from '@ember/test-helpers';
|
|
import hbs from 'htmlbars-inline-precompile';
|
|
import Service from '@ember/service';
|
|
|
|
//Stub location service
|
|
const locationStub = Service.extend({
|
|
city: 'New York',
|
|
country: 'USA',
|
|
currentLocation: {
|
|
x: 1234,
|
|
y: 5678
|
|
},
|
|
|
|
getCurrentCity() {
|
|
return this.get('city');
|
|
},
|
|
getCurrentCountry() {
|
|
return this.get('country');
|
|
}
|
|
});
|
|
|
|
module('Integration | Component | location indicator', function(hooks) {
|
|
setupRenderingTest(hooks);
|
|
|
|
hooks.beforeEach(function(assert) {
|
|
this.owner.register('service:location-service', locationStub);
|
|
});
|
|
|
|
test('should reveal current location', async function(assert) {
|
|
await render(hbs`{{location-indicator}}`);
|
|
assert.equal(this.element.textContent.trim(),
|
|
'You currently are located in New York, USA');
|
|
});
|
|
});
|
|
|
|
|
|
/*
|
|
* Unit & container tests
|
|
*
|
|
* Unit tests (as well as container tests) are generally used to test a
|
|
* small piece of code and ensure that it is doing what was intended.
|
|
*/
|
|
|
|
// app/services/some-thing.js
|
|
import Service from '@ember/service';
|
|
|
|
export default Service.extend({
|
|
foo: 'bar',
|
|
|
|
testMethod() {
|
|
this.set('foo', 'baz');
|
|
}
|
|
});
|
|
|
|
// tests/unit/services/some-thing-test.js
|
|
import { module, test } from 'qunit';
|
|
import { setupTest } from 'ember-qunit';
|
|
|
|
module('Unit | Service | some thing', function(hooks) {
|
|
|
|
// The `setupTest` helper provides us with some conveniences, such as the `this.owner` object,
|
|
// that helps us to create or lookup objects which are needed to setup our test.
|
|
// In this example, we use the `this.owner` object to lookup the service instance that
|
|
// becomes our test subject: `someThing`. Note that in a unit test you can customize any
|
|
// object under test by setting its properties accordingly. We can use the `set` method
|
|
// of the test object to achieve this.
|
|
setupTest(hooks);
|
|
|
|
test('should update foo on testMethod', function(assert) {
|
|
const someThing = this.owner.lookup('service:some-thing');
|
|
|
|
someThing.testMethod();
|
|
|
|
assert.equal(someThing.get('foo'), 'baz');
|
|
});
|
|
});
|
|
|
|
|
|
/*
|
|
* Running tests
|
|
*
|
|
* Run your tests with `ember test` on the command-line. You can re-run your tests on
|
|
* every file-change with `ember test --server`.
|
|
*
|
|
* Tests can also be executed when you are running a local development server
|
|
* (started by running `ember server`), at the `/tests` URI which renders the `tests/index.html` template.
|
|
*/
|
|
|
|
```
|
|
ember test
|
|
ember test --server
|
|
ember test --filter="dashboard"
|
|
run ember server then visit http://localhost:4200/tests
|
|
```
|
|
|
|
|
|
|
|
/*
|
|
* 09 | Addons
|
|
* --------------------------------------------------------------
|
|
*
|
|
* Ember has a rich ecosystem of addons that can be easily added to projects.
|
|
* Addons provide a wide range of functionality to projects, often saving time and
|
|
* letting you focus on your project.
|
|
*
|
|
* To browse addons, visit the [EmberObserver](https://emberobserver.com/) website. It catalogs and categorizes Ember
|
|
* addons that have been published to NPM and assigns them a score based on a variety of criteria.
|
|
*
|
|
* > ember install <addont-name>
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
* 10 | Configuration
|
|
* --------------------------------------------------------------
|
|
*
|
|
* Ember CLI ships with support for managing your application's environment. Ember CLI
|
|
* will setup a default environment config file at config/environment. Here, you can define
|
|
* an ENV object for each environment, which are currently limited to three: development,
|
|
* test, and production.
|
|
*/
|
|
|
|
// The ENV object has three important keys:
|
|
// - `EmberENV` can be used to define Ember feature flags (see the Feature Flags guide).
|
|
// - `APP` can be used to pass flags/options to your application instance.
|
|
// - `environment` contains the name of the current environment (development,production or test).
|
|
|
|
// You can access these environment variables in your application code by importing from `your-application-name/config/environment`.
|
|
import ENV from 'your-application-name/config/environment';
|
|
|
|
if (ENV.environment === 'development') {
|
|
// ...
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
* 11 | Community
|
|
* --------------------------------------------------------------
|
|
*
|
|
* Ember's secret sauce
|
|
*
|
|
* more at [Ember Community Page](https://emberjs.com/community/)
|
|
*
|
|
*/
|
|
|
|
// Ember Discussion Forum
|
|
//
|
|
// url: http://discuss.emberjs.com/
|
|
//
|
|
// A great venue for discussing things like features, architecture, and best practices
|
|
// and a great place to ask questions (and get great answers from Ember Core Team members
|
|
// and other members of the community)
|
|
|
|
// Ember Community Slack
|
|
//
|
|
// url: https://embercommunity.slack.com/
|
|
//
|
|
// Use the Slackin app to receive an invitation.
|
|
|
|
// Ember Times
|
|
//
|
|
// url: https://the-emberjs-times.ongoodbits.com/
|
|
//
|
|
// Follow the progress of new features in the Ember ecosystem, requests for community
|
|
// input (RFCs), and calls for contributors
|
|
|
|
// Ember Weekly
|
|
//
|
|
// url: http://www.emberweekly.com/
|
|
//
|
|
// A curated list of Ember learning resources (podcasts, videos, blog posts, books, and more)
|
|
|
|
// Official Ember Blog
|
|
//
|
|
// url: https://emberjs.com/blog/
|
|
//
|
|
// Big announcements like new Ember.js version release notes or State of the Union information
|
|
|
|
// Ember Github
|
|
//
|
|
// url: https://github.com/emberjs/
|
|
|
|
// Ember Meetups
|
|
//
|
|
// url: https://emberjs.com/community/meetups/
|