Добавил автоматический мигратор на этот кейс.

Добавил автоматический мигратор на этот кейс.

@miripiruni
почему здесь проверка есть, а в аналогичном шаблоне button_togglable_radio — нет? она ведь не нужна на самом деле?

Я слишком далек от бизнес-логики в этих шаблонах. Но судя по тому что написано в них и в их тестах aria-pressed не должна генерироваться в checkbox_type_button.

Вот здесь явно обнуляется этот атрибут: https://github.com/bem/bem-components/blob/v5/common.blocks/checkbox/_type/checkbox_type_button.bemhtml.js#L17

И чтобы это работало как следует, я добавил это условие в шаблоне.

@miripiruni
расскажи про это изменение, пожалуйста. выглядит странно и опасно в плане отсутствия возможности дальнейшего переопределения в пользовательском коде

Похоже тут ты прав и это совершенно лишнее.

Убрал.

я правильно понимаю, что applyNext() и последующие проверки позволяют предоставить приоритет значениям из BEMJSON?

кажется, что в итоге в целом по библиотеке получается непредсказуемое поведение: часть шаблонов такие проверки добавляет, часть нет.

я правильно понимаю, что applyNext() и последующие проверки позволяют предоставить приоритет значениям из BEMJSON?

applyNext() позволяет получить значение из предыдущего шаблона. А вот как это значение будет использовано — уже дело разработчика.

Я повторюсь, в этом PR я восстанавливал поведение тестов, потому как оценить такой объем шаблонов и все связи мне не представляется возможным за такой короткий срок.

Я так понимаю, что ты беспокоишься именно из-за случаев с something: undefined. Но тут это дело скорее логики bem-components чем шаблонизатора как такового.

Блок А генерит в качестве содержимого BEMJSON с блоком Б, в котором явно обнуляется какой-то атрибут. В шаблоне блока Б есть addAttrs() в котором этот атрибут генерируется исходя из каких-то третих условий. addAttrs() сам по себе безусловно добавляет этот атрибут. Единственный способ из блока А отказаться от атрибута блока Б это поступить так:

1. явно прописать значение undefined в BEMJSON.
2. в шаблоне блока Б проверять на значение undefined.

И всё это на уровне решений, которые принимает разработчик.

Я понимаю технические причины, меня здесь в первую очередь смущает глобальная проблема: данный кейс не такой уж редкий, чтобы можно было его игнорировать, а сравнение было/стало очень не в пользу новой реализации.

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

В общем, я хочу, чтобы меня доубедили, что миграция на новую версию несет больше добра, чем вреда :)

Давай-ка пообщаемся голосом. Я не понимаю почему ты считаешь «глобальной проблемой» желание на проекте иметь два описания одного и того же блока:

1. если у блока есть поле в bemjson со значением undefined
2. если у блока нет поля в bemjson.

Плюс, я смотрю на дифф и не понимаю, что здесь стало сильно хуже. ИМХО, здесь изменения не про читаемость или компактность. А только про больший контроль в руках разработчика — код стал очевидный (написано что происходит), тогда как раньше кода про решение какое значение атрибута выбрать просто не было — это решение неявно принималось внутри шаблонизатора.