Issue #168: implement content escaping (take 2)

[miripiruni]

Instead of #178

• Docs
• escapeContent flag
• Special content value: { html: '…' }
• Tests
• Benchmarks

Benchmarks

results for 10000 runs:

average diff 1% (from 1μs) slower on apply() and the same on compile()

compile:granny:next x 596 ops/sec ±0.36% (10027 runs sampled)
compile:granny:prev x 601 ops/sec ±0.35% (10030 runs sampled)
–0.83% от 1ms

render:granny:next x 1,153,802 ops/sec ±0.23% (10033 runs sampled)
render:granny:prev x 1,257,028 ops/sec ±0.20% (10033 runs sampled)
–8,2% от 1μs


compile:islands:next x 192 ops/sec ±0.30% (10023 runs sampled)
compile:islands:prev x 190 ops/sec ±0.30% (10023 runs sampled)
~ the same

render:islands:next x 433 ops/sec ±0.19% (10029 runs sampled)
render:islands:prev x 442 ops/sec ±0.18% (10030 runs sampled)
–1,58% от 1ms


compile:serp:next x 25.51 ops/sec ±0.61% (10015 runs sampled)
compile:serp:prev x 24.86 ops/sec ±0.96% (10016 runs sampled)
~ the same

render:serp:next x 1,146,380 ops/sec ±0.55% (10033 runs sampled)
render:serp:prev x 1,169,145 ops/sec ±0.56% (10032 runs sampled)
–1,94% от 1μs 

Islands & shocase bemhtml outdated.

The plan:

1. minor release with escapeContent:false option.
2. major release with escapeContent:true option.

[qfox]

Хотя, если не обрабатывается toString, то там можно вывести блоки без экранирования? Так, чтоли?

[miripiruni]

@zxqfox nope.

{
    html: { block: 'test', content: 'H&M' }
}

Will treated as:

{}

<div></div>

because of typeof html !== 'string' therefore html — will treated as user defined field.

[qfox]

Black magic.

👎

[veged]

если мы не хотим разрешать в html ничего кроме строк, то нужно явно кидать ексепшен в этом месте, а не делать так, чтобы объекты с toString рендерились не в строку

[veged]

я так и не понял, что мы делаем для кейсов, когда там не строка, а объект? точно мы не хотим бросать эксепшен??

[qfox]

У нас люди не очень любят эксепшны. Мы можем подумать в сторону варнингов, чтобы писать про такое в логи, например.

[miripiruni]

Дело не в том, что любят люди :)

Просто я бы не стал никак делать лишних ограничений. Есть поведение задекларированное и мы будем его поддерживать (передавай строку), а всё остальное не гарантируется, используй на свой страх и риск.

[qfox]

Вообще, я за как можно меньше доп логики в шаблонизаторе — нет смысла в лишних проверках, жрущих CPU и требующих документации. Проверка на какие-то поля block/elem/tag/content (?) кажется вполне разумным компромисом, учитывая что мы не можем проверить просто html, потому что это кому-то что-то может сломать (мажор может просто?).

[veged]

Big question about benchmarks! Now they are go to dissemble («a little bit») because in BEMJSON there is not so many text nodes. basic.bemjson more over is too small even for any other benchmarks.

I suggest to add one more example similar to SERP in terms of total amount of different blocks (for other benchmarks) and in terms of proportions between BEM-entities and their text content (for this particular case of benchmarking).

[veged]

скорее «является специальным типом возможных объектов в BEMJSON» — как минимум, потому, что я могу написать

{
  block: 'b1',
  content: [
    '1',
    { html: '2' },
    '3'
  ]
}

и это уже не будет всем значением поля content

[mishanga]

html является специальным полем объекта в BEMJSON

[qfox]

@mishanga Это в bh ;-)

[miripiruni]

скорее «является специальным типом возможных объектов в BEMJSON»

Fixed.

[miripiruni]

Rebased from master.

[miripiruni]

To all: so, let’s merge it today?

[veged]

can't catch what exactly numbers for bench results?

[miripiruni]

@veged depends on project. But average diff +1% on apply() and the same on compile(). See PRs description.

[veged]

please, put this in clearly description ;-) and merge

[miripiruni]

Description updated.