@RALifeCoach @pYr0x
5) Use computes like a mad man. The goal is to lower unnecessary change events. For example, the isAdmin getter I described above is actually really performant, as now I can bind to it elsewhere, and something like changing users or logging in that would trigger isAdmin to be re-computed wouldn’t trigger other computes that are dependent on isAdmin from re-computing if isAdmin doesn’t change
isAdmin: {
get: function() {
var profile = this.attr('profile');
if (profile) {
return profile.attr('tier') === config.tiers.indexOf('admin');
}
return false
}
}
Changing profile / tier would recompute this. But if the value hasn't changed, computes dependent on this wouldn't recompute
ok.. and what about the point 5) bajix said?
Computes cache if they're bound, and then re-compute whenever an observable they've bound to changes. Only if the re-computed value is different will it then emit a change event. So the general technique is to utilize computes for intermediate values, such that more expensive, poorly-cacheable computes would be re-computed less frequently. This is especially true for Component helpers, as new Document Fragments that would otherwise be identical still need to be re-rendered.
There's no need to shy away from components within loops either if that means that you're better able to accomplish the above. Using an extra component wins out if it reduces unnecessary DOM manipulation.
For example, the Chat app I work on uses a message
component when iterating user messages. Consecutive messages from the same author are grouped, and messages can come out of order; using a component to manage state based off of the prev/next message means my section helpers trigger O(n^3)
times less often.
TLDR; Make cache-able computes. Use cache-able intermediates. Win at helpers. Win at computed objects.
can.map.define
plugin?
set
setter on that prop that invoke your method
signPromise: {
get(lastval, set) {
return Sign.getList({...});
},
set(newval) {
}
},
sign: {
get(lastval, set) {
this.attr('signPromise').then(function(signs) { set(signs[0]);}
},
set(newval) {
}
}
further to this discussion, I have a component with it’s internal viewModel i.e.
can.Component.extend({
tag: ‘my-component’,
template: can.view(‘#some-template’),
viewModel: {
define: {
xxx: { type: ‘string’ }
}
}
});
I add the component to my page via:
var template = can.stache(‘<my-component id="me"></my-component>’)
$(‘body”).append(template());
var myComponent = $(‘#me’);
myComponent.bind(??????);
I want to bind to the component to know when the value of xxx changes.
sign
changes
fall-through-cache
behavior so I dont know how it realy does things :/
can.Component.extend({
tag: ‘my-component’,
template: can.view(‘#some-template’),
viewModel: {
define: {
xxx: { type: ‘string’ }
}
},
events: {
"{viewModel} xxx":function(){
}
}
});
"type": "*"
no
, you are not binding on "change"
events?
var template = can.stache('<player-row id="player-row-{{pid}}" {pid}="pid" {parent}="parent"></player-row>');
var fragment = template({
pid: this.pid,
parent: this
});
toString
ing your object
template({pid: '11111', player: player})
with the initial data from the server
@justinbmeyer in many ways my code is quite simple. All data is display only. There is some binding against controls, but not against the data itself.
iiiii ppppp
@justinbmeyer in many ways my code is quite simple. All data is display only. There is some binding against controls, but not against the data itself.
@RALifeCoach if that's the case, I wouldn't convert it to a Map at all