Add better component example

[Gorzas]

Close #152

[offirgolan]

@Gorzas I dont believe that replacing init with didUpdateAttrs is an ideal implementation (especially in a simple example). The component life cycle hooks didUpdateAttrs and didReceiveAttrs can fire pretty frequently and can ultimately cause unwanted circumstances for new users that are not aware of its implications.

[Gorzas]

Thanks for checking my PR @offirgolan. I didn't replace init with didUpdateAttrs, I've just added this option. I know it's a simple example but setting table only in the init method could come to errors in the implementation that are difficult to debug for new users. Can we add it in the example but with a warning?

[offirgolan]

@Gorzas didUpdateAttrs is not a place you want to keep creating new instances of the table. Instead you can easily use a CP for that and even keep the same table instance

How about something like this instead:

export default Ember.Component.extend({
  model: null,

  columns: computed(function() {
    return [{
      label: 'Avatar',
      valuePath: 'avatar',
      width: '60px',
      sortable: false,
      cellComponent: 'user-avatar'
    }, {
      label: 'First Name',
      valuePath: 'firstName',
      width: '150px'
    }, {
      label: 'Last Name',
      valuePath: 'lastName',
      width: '150px'
    }, {
      label: 'Address',
      valuePath: 'address'
    }, {
      label: 'State',
      valuePath: 'state'
    }, {
      label: 'Country',
      valuePath: 'country'
    }];
  }),

  table: computed('model.[]', function() {
    /*
      Set the table rows when our model changes
     */
    this.get('_table').setRows(this.get('model'));

    return this.get('_table');
  }),

  init() {
    this._super(...arguments);

    /*
      Create our table instance
     */
    this.set('_table', new Table(this.get('columns')));
  }
});

Not sure I like using _table in the readme though so maybe a better name is appropriate. Maybe this should be a separate example altogether which can show an improved way of doing things on top of the basic example?

In the future, we will implement a way of automatically doing this so there wont be a need for any of this.

[taras]

Computed properties are not supposed to have side effects. If you're going to do this, then you might as well use an observer.

[Gorzas]

@offirgolan I have changed the example again, you can take a look. It seems that we may include two examples instead of only one. What do you think?

Note: I have change my commit with a rebase, I don't know if this way is better or if it's better to include an extra commit instead.

[offirgolan]

@Gorzas this will not longer be necessary once #167 lands 😺