Skip to content

Instantly share code, notes, and snippets.

@jcardoz
Last active July 25, 2017 13:19
Show Gist options
  • Save jcardoz/69df75f88d782aca679b0b7aeadac6ee to your computer and use it in GitHub Desktop.
Save jcardoz/69df75f88d782aca679b0b7aeadac6ee to your computer and use it in GitHub Desktop.
Ember Optimization & Best Practices Checklist
Simple Complexity Changes
- Move translations from JS to HBS file
- Use ES6 fat arrow instead of anonymous functions
- Remove 'self' and use 'this' instead. This will tie with the previous rule, since the fat arrow allows for use of 'this'
from the parent scope, rather than needing a variable like 'self' or 'that' for context
  - Computed properties are awesome and should be used whenever possible.
Computed properties prevent us from doing a lot of setting or getting of different variables in our code.
   
A lot of useful computed property helper functions are built into Ember.
An Example: Ember.computed.gt (gt stands for GreaterThan)
This computed property returns true if the original value for property is greater than the given value.
showContinueButton: Ember.computed.gt(‘lastStepValue’, ‘currentStepValue’);
Refer to the following link for the complete list of helper functions:
http://coderberry.me/blog/2013/07/07/useful-functions-in-the-ember-namespace/
- Do not set another property within a computed property.
This is a bad practice. Rather the other property which is being set can be another computed property with a dependency on the
first.
- Do not use bind-attr for class names / properties since this feature is now deprecated. For simple true false logic, use if within the handlebar
template. Otherwise, use a computed property and place this within the class attribute: class = '{{myComputedClass}}'
- Setting up properties within the didInsertElement should not be done.
Rather use the init or didReceiveAttrs life cycle events. didInsertElement should only be used in case of setting up anything
that requires the DOM to be ready. This could be a 3rd party jQuery library. Otherwise do not use the didInsertElement.
- Use constants - This is to be followed for Logging (Logger), run later and schedule (run), computed properties (computed) and even
jQuery ($). Anything being used multiple times within your file can be considered and add to the const at the top of the file
- Use the Data Down Action Up paradigm for your components. A component should receive input from the parent route or controller and
then trigger a sendAction back to the parent when an action is performed
- Use ES6 features when possible: Simple example of this is using string interpolation or tics (``) for creating a string, rather
than using + to concatenate strings. Variables can be written as follows - `${someVariableName}`
- Do not use alert or console.log statements. Rather use Ember.Logger.info for logging messages.
This is necessary so that when we perform a production build, the logging code will be removed.
- ES6 version of functions: Rather than using myFunction: function() {...}, simply use myFunction(){}
- SASS lint error resolution
- Use single quotes over double quotes - In case your string has a quote within it - use an escape character \' or \" to escape the
quote
- Code commenting is a MUST. This will help in documentation and also code readability and maintainability.
For function declaration blocks and for defining various sections within a file, use the block level comment.
/*
/ This is an awesome comment written
/ in block style
*/
- For comments explaining the code functionality, use the single line style of comments
// This is another awesome single line comment
Medium Complexity Changes
- Remove on('init') or on('didInsertElement') and use init() with this.super(...arguments) to call parent class functions
High Complexity Changes
- Remove observes and replace with computed properties
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment