Provide data context methods with different equality about meteor-blaze-components HOT 6 CLOSED

sounds sensible

how about if you use .data() inside constructor: -> it is considered structural, and anywhere else it's referential?

from meteor-blaze-components.

I do not think that having different semantics based on where you call a function is a good API.

from meteor-blaze-components.

could have the default behaviour as referential, and a parameter for setting as structural

.data({structural:true})

from meteor-blaze-components.

I think we should leave default behavior as it is in Blaze. Just to minimize surprises. Default Blaze behavior is the most conservative one, it means functions/methods are rerun more often, but then Blaze does not necessary really modify DOM if everything stays the same. So this is a good default. It does not introduce any errors.

from meteor-blaze-components.

In fact, because I have not seen really non-object data contexts in practice, this means that the whole Blaze behavior is more similar to React.js: rerun everything and then compare with DOM and patch it if there are changes. The issue is that React.js uses virtual DOM do make comparison, while Blaze I think compare with real DOM. And reading real DOM is a bit slower than virtual DOM.

from meteor-blaze-components.

I think now that we have computed fields this is not really necessary. If you need different equality you can do:

onCreated: ->
  @dataStructural = new ComputedField (=> @data()), EJSON.equals

And this is it. :-) And then you can call @dataStructural() to get data context which will trigger reactive change only when data is structurally different.

For referential equality:

onCreated: ->
  @dataReferential = new ComputedField (=> @data()), (a, b) => a is b

from meteor-blaze-components.