Skip to content

Latest commit

 

History

History
185 lines (152 loc) · 4.42 KB

ember.md

File metadata and controls

185 lines (152 loc) · 4.42 KB

Ember

  1. General Structure
  2. Destructuring
  3. CSS
  4. Actions

General Structure

  • 1.1 Property Order: For components and controllers, follow this order for properties and methods
    • Properties
      • Put ember specific properties (e.g., classNames, tagNames) before custom properties (e.g., someSpecificAshProp : true)
    • Component lifecycle hooks (in order) see order in documentation
    • Custom methods
    • actions go last

Destructuring

Extract multiple values from data stored in objects and arrays.

Why? Destructuring allows you to import only which classes you need and then extract (or destructure) only the properties that you need. This makes our modules more efficient.

2.1 Destructuring Objects

//Bad
export default DS.Model.extend({
  firstName: DS.attr('string'),
  lastName: DS.attr('string'),
  fullName: Ember.computed('firstName', 'lastName', function() {
    //compute full name
  })
});

//Good
import Ember from 'ember';
import DS from 'ember-data';

const {
  computed
} = Ember;

const {
  Model,
  attr
} = DS;

export default Model.extend({
  firstName: attr('string'),
  lastName: attr('string'),
  fullName: computed('firstName', 'lastName', function() {
    //compute full name
  })
});

2.2 Using get and set

Destructuring get and set will allow you pass in a POJO, rather than being limited to just the current object with the this keyword.

//Bad
this.set('isDestructured', false);
this.get('isDestructured'); //false

//Good
import Ember from 'ember';

const {
  get,
  set
} = Ember;

set(this, 'isDestructured', true);
get(this, 'isDestructured'); //true

set(someObject, 'isUpdated', true);
get(someObject, 'isUpdated'); //true

CSS

3.1 Usage

CSS is permitted (and encouraged) in apps and addons under certain circumstances

Why? Flow, interaction and breakpoints generally belong to the component and not the domain (host site). Properties such as colors, fonts styles, etc. should belong to host site, so that each site can have its own identity. Moving CSS into component files will also cut down on the size of domain CSS bundles and help mitigate the issue of shipping a lot of CSS that belongs to components not in use on that site.

Properties Allowed:

  • Box Model
  • e.g., padding, height, margin, border-width
  • Display
  • e.g., display:flex, flex-direction: column
  • Animations and Transitions

Examples of Properties to Not use

  • Colors
  • e.g., color, background
  • Text styles
  • e.g., font-weight, font=family
// Bad
// app/style/appName.scss
.chats {
  padding: 1rem;
  display: flex;
  background: $color1;

  .chatMsg {
    font-weight: 700;
    text-transform: uppercase;    
    background: $color2;
    color: $color1;
    transition: all 1s ease-in-out;
  }
}

// Good
// base/social.scss
.chats {
  background: $color1;

  .chatMsg {
    font-weight: 700;
    text-transform: uppercase;    
    background: $color2;
    color: $color1;
  }
}

// app/style/appName.scss
.chats {
  padding: 1rem;
  display: flex;

  .chatMsg {
    transition: all 1s ease-in-out;
  }
}

Actions

4.1 Location

  • Form Actions should be placed on the form element
//Bad
<form>
  <input id="firstName" type="text" />
  <input id="lastName" type="text" />
  <button type="submit" {{action 'SubmitForm'}}> Submit</button>
</form>

//Good
<form {{action 'SubmitForm' on='submit'}}>
  <input id="firstName" type="text" />
  <input id="lastName" type="text" />
  <button type="submit"> Submit</button>
</form>
  • Button actions that are not in a <form> should be placed on the <button> itself
//Bad
<div class="container" {{action 'showHide'}}>
 <button type="submit">Submit</button>
</div>

//Good
<div class="container">
 <button type="submit" {{action 'showHide'}}>Submit</button>
</div>