У нас есть угловое приложение, и недавно мы добавили механизм, который позволяет пользователям по желанию загружать пользовательский шрифт, а затем отображать приложение в этом пользовательском шрифте.Парень, который его реализовал, добавил директиву, которая объявляет блок и определяет переопределение шрифта на основе настроек пользователя на странице.
То, что подправило команду QA, заключается в том, что перед возвращением этих данных настройки ониВы видите запрос 404 для / {{fontPath}} / {{customFont}} до тех пор, пока не пройдут все циклы дайджеста.
Я пытался заставить 404 уйти и столкнулся с некоторымивещи, которые меня озадачивают.
Во-первых, вот как это выглядит
<div font-override ng-if="customFont"></div>
, и директива templateUrl выглядит как
<style>
@font-face {
font-family: 'FontOverride';
src: url("{{fontPath}}{{customFont}}") format('woff');
font-weight: normal;
font-style: normal;
}
@font-face {
font-family: 'FontOverride';
src: url("{{fontPath}}{{customFont_bold}}") format('woff');
font-weight: bold;
font-style: normal;
}
@font-face {
font-family: 'FontOverride';
src: url("{{fontPath}}{{customFont_italic}}") format('woff');
font-weight: normal;
font-style: italic;
}
@font-face {
font-family: 'FontOverride';
src: url("{{fontPath}}{{customFont_boldItalic}}") format('woff');
font-weight: bold;
font-style: italic;
}
.ourApp *:not(.fa) {
font-family: 'FontOverride' !important;
}
</style>
И когда содержимое templateUrl обменивается, есть немедленный 404 запрос на "/ {{fontPath}} {{customFont}}"
Я играл с кучей вещей, пытаясь заставить это уйти.Я поместил ng-cloak как в div, так и внутри содержимого templateUrl.Это не сработало.
Я попытался определить стиль ng-cloak и установить его в качестве класса css на узле стиля (нашел это в другой стопке из следующей статьи), но это не сработало.
На дикомЗаяц, я попытался взять содержимое файла templateUrl и встроить его в код директивы с литералом шаблона
template: ``
Сначала это не сработало, но началось после того, как я удалил кавычки вокруг URL ("{{fontPath}} {{customFont}} ").
Непонятно, почему, как и в какой момент шаблон решается или почему это работает лучше (по сравнению с 404), чем templateUrl.Я имею в виду, что из того, что я нашел в ECMA6, фактические биты шаблона равны $ {}, а не {{}}.
Затем я попробовал это в IE11 (так как мы все еще номинально это поддерживаем) и, конечно,шаблонные литералы там не работали.Поэтому я попытался создать многострочную вещь как старую строку
"<style>\r\n" +
" @font-face { font-family: 'FontOverride'; src: url('{{fontPath}}{{customFont}}') format('woff'); font-weight: normal; font-style: normal; } \r\n\r\n" +
...
" .ourApp *: not(.fa) {\r\n font-family: 'FontOverride' !important;\r\n }\r\n</style>\r\n"
Последняя строка стиля казалась более чувствительной к новой строке / пробелу, поэтому я пытался ее сохранить.
Это работало ни в одном браузере, который я пробовал.Chrome, IE, Edge отображали его одинаково, когда я проверял элементы, но шрифт не был ни получен, ни применен на каком-либо этапе.Firefox, по-видимому, в первую очередь удаляет символы новой строки из литерала.
Итак ... 1) Почему template: `` работал без выдачи запроса 404 в первую очередь?
2) я пытался использовать шаблонные литералы ECMA6 просто для получения многострочных констант;Я не ожидал, что конструкции шаблона будут работать напрямую, поскольку ECMA6 использует $ {} вместо {{}}, но, возможно, литералы шаблона EMCA6 также получают угловой синтаксис?Или, может быть, angular использует синтаксис jquery и создает своего рода синоним?
3) Почему неуклюжий старый строковый литерал с \ r \ n в них отображается одинаково в большинстве браузеров, но не оказывает функционального влияния?Кинда возвращается к теории о том, что литералы шаблонов ECMA6 оцениваются по-разному по-разному.
Оценка приветствуется.
Thx.