142a7217d4
These bindings can be replaced wholesale with the more idiomatic alternative: aliases. In addition, avoid passing in user to components where it can be injected directly. One of the perceived downsides of dependency injection can be that it can make debugging feel more difficult because it's not immediately clear where the value is coming from, which the explicit variant we previously used does not suffer from. It might also be argued that we also lose out on a seam that could be useful in the future where a component doesn't care about the specific type of user, just that one is passed in. While explicitness is often a virtue, it comes at the cost of increased noise that pervades multiple layers of components. I'd argue this makes the parent components more difficult to understand, given they are littered with unnecessary references to data they themselves do not need. This decreases the noise/ceremony around accessing userPermissions/auth data and restricts access to that data to the child components that actually need to know about it. As to losing a seam, it appears 1) that this isn't currently necessary and 2) we can use an internal computed property should the need arise in the future.
16 lines
339 B
JavaScript
16 lines
339 B
JavaScript
import Ember from 'ember';
|
|
import attr from 'ember-data/attr';
|
|
import Model from 'travis/models/model';
|
|
|
|
const { alias } = Ember.computed;
|
|
|
|
export default Model.extend({
|
|
name: attr(),
|
|
type: attr(),
|
|
avatarUrl: attr(),
|
|
reposCount: attr('number'),
|
|
subscribed: attr('boolean'),
|
|
education: attr('boolean'),
|
|
login: alias('id')
|
|
});
|