Как жить без наследования в шаблонах закрытия в большом проекте?

Мы используем библиотеку закрытия и компилятор закрытия, и мы хотим использовать шаблоны закрытия.

Но шаблоны закрытия не имеют наследования. Это действительно проблема для нас.

Насколько я понимаю, причина, по которой шаблоны закрытия не имеют наследования, заключается в том, что шаблоны должны быть простыми и легко читаемыми.

Но как жить без наследования в больших проектах?

Например, у нас есть файл шаблона button.soy, который создает кнопку с общедоступным шаблоном project.createButton и частными шаблонами: project.createOpenTag_, project.createCSSClasses_, project.createAttributes_, project.createContent_, project.createCloseTag_.

У нас есть класс JavaScript project.Button и project.ButtonCircle (возможно, этот отдельный класс project.ButtonCircle кажется ненужным, но это просто пример), который расширяет project.Button.

project.ButtonCircle необходимо внести небольшие изменения в шаблон project.createButton.

Конечно, мы можем добавить новый функционал в project.createButton, но это очень плохая идея, потому что такой подход создаст шаблоны монстров в будущем.

Или мы можем создать общедоступный шаблон project.createCircleButton в файле button-circle.soy, вызывать в нем все приватные шаблоны из project.createButton, и когда нам нужно «переопределить» один из этих приватных шаблонов (например, project.createCSSClasses_) , мы просто создаем новый приватный шаблон в button-circle.soy с именем project.createCSSClassesCirbleButton_.

Однако в этом случае нам нужно скопировать и вставить все содержимое с project.createButton на project.createCircleButton. Это ужасно.

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

Каков подход к этой проблеме?


javascript inheritance templates google-closure-templates soy-templates
person Boyo    schedule 23.09.2015    source источник
comment
наследование не должно быть автоматическим/собственным, чтобы быть полезным, возможно, вы можете перебирать исходные свойства/методы и копировать их в новую цель вместо того, чтобы позволять им естественным образом просачиваться; что-то вроде инструментов javascript extend() против наследования на основе прототипов...   -  person dandavis    schedule 29.09.2015

Ответы (3)


arrow_upward
2
arrow_downward

Трудно определить ваш точный вариант использования, но, широко использовав soy/close в свое время в Google, я сочувствую вашему недоумению, поскольку они не мои любимые. Я согласен с общим предложением @Francois-Richard о том, чтобы общие шаблоны были очень маленькими и составляли несколько вместе. Модель soy (и многие другие системы шаблонов JS, которые я честно использовал) решительно отдает предпочтение композиции, а не наследованию.

Расширение

Если CircleButton логически и стилистически такой же, но только с добавленной функциональностью или стилем, тогда композиция будет работать отлично.

<div class="circle">
  {call .button}
</div>

Параметризация

Если CircleButton логически одинакова, но стилистически отличается, почему бы не разрешить параметризацию Button по форме и повторное использование одного и того же шаблона?

{call .button shape="circle" /}

Композиция

Если CircleButton не является ни логически, ни стилистически одинаковым, а просто разделяет некоторые базовые элементы, извлеките их в шаблоны/классы и используйте композицию.

<div class="circle">
  {call .buttonSharedA /}
  <span>{call .buttonSharedB /}</span>
</div>

Соя действительно не согласуется с остальной частью закрытия по сравнению с ОО-мышлением ИМХО и просто требует другого подхода.

person Patrick    schedule 01.10.2015

arrow_upward
0
arrow_downward

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

person François Richard    schedule 01.10.2015

arrow_upward
0
arrow_downward

Мы просто пишем препроцессор, который добавляет @extends к soy.

person Boyo    schedule 26.05.2016