Push html to `this._str`

[bem]

Push html to `this._str`

[veged]

we use it for flushing/streaming content

[indutny]

@veged: I know, but this is now what I meant. Current 2.x implementation does this stuff in a following way:

block('b1').def()(function() {
  return '<div>' + applyNext() + '</div>';
});

Strictly speaking, this is much more clear than (old i-bem):

block('b1').def()(function() {
  this._str += '<div>';
  applyNext();
  this._str += '</div>';
});

I would prefer first style, and it is not that big pain to switch over to it. So the question is can we afford this?

[veged]

but what we gonna do with apply* cals? not all of .def() templates returning value, some redefines just call applyNext

[indutny]

Why not require them to return a value now?

[veged]

we need to do like that:

block('b1').def()(function() {
  return applyNext({ '_bla': 1 });
});

but right now we do just:

block('b1').def()(function() {
  applyNext({ '_bla': 1 });
});

[indutny]

Yes, exactly. Can we change this, and/or ask people to change it? Seriously, the internal implementation will be much simpler this way (and probably faster).

[veged]

ok — let's suppose we can do this in v2

[indutny]

great! :)

[indutny]

THIS IS REQUIRED FOR FLUSHING/STREAMING

Could be possibly skipped in case where we don't need to flush/stream things. So templates should use return with applyCtx() anyway.

[indutny]

Proposed implementation is here: 51dee47 . No performance regression without _flush, and with it.

[indutny]

Looks like it isn't done:

block(‘b1’).def()(function() { return ‘#’ + applyNext(); })

[indutny]

Test case fixed in 678e33e. However a bigger question remains.

Particularly, block page overrides def() mode, making this _flush feature useless.

Second question is speed: current implementation of _flush slows things by 2-5% with disabled flush. If there won't be resolution for the block page - we should consider removing this feature on initial release.

[indutny]

And this is done in:

fccd9d4

compile:basic:next x 1,919 ops/sec ±1.09% (558 runs sampled)
compile:basic:prev x 1,937 ops/sec ±1.19% (562 runs sampled)
render:basic:next x 770,381 ops/sec ±0.23% (592 runs sampled)
render:basic:prev x 820,049 ops/sec ±0.20% (592 runs sampled)
flush:basic:next x 703,103 ops/sec ±0.24% (591 runs sampled)
flush:basic:prev x 832,992 ops/sec ±0.17% (593 runs sampled)
compile:islands:next x 608 ops/sec ±0.95% (558 runs sampled)
compile:islands:prev x 617 ops/sec ±0.90% (556 runs sampled)
render:islands:next x 1,415 ops/sec ±0.26% (588 runs sampled)
render:islands:prev x 1,462 ops/sec ±0.16% (588 runs sampled)
flush:islands:next x 1,445 ops/sec ±0.23% (588 runs sampled)
flush:islands:prev x 1,448 ops/sec ±0.20% (586 runs sampled)
compile:showcase:next x 587 ops/sec ±0.96% (558 runs sampled)
compile:showcase:prev x 596 ops/sec ±0.93% (556 runs sampled)
render:showcase:next x 2,633 ops/sec ±0.29% (586 runs sampled)
render:showcase:prev x 2,592 ops/sec ±0.29% (587 runs sampled)
flush:showcase:next x 2,305 ops/sec ±0.57% (579 runs sampled)
flush:showcase:prev x 2,469 ops/sec ±0.27% (589 runs sampled)

Doesn't look like significant regression in _flush. I guess it should be fine to release 2.x with this feature ;)