Strapi решение крутое и очень гибкое, но, альфу версию нельзя использовать в проде это прямым текстом в документации прописано. А стабильная версия не обладает тем крутым функционалом что свеженькая альфа, и миграция потом будет жестокой.
Кто-нибудь находил аналогичный стабильный продукт (не облачное решение)?
Это тоже самое, только так называемый спрайт у вас присутствует в теле html а не во внешнем файле.
При таком подходе мне не понятно, зачем вообще делать <use xlink:href="#icon-coffee" href="#icon-coffee" /> Если можно сразу вставить svg код в нужное место, и без извращений поменять цвет, рамер… да что угодно. Это железно работает везде.
Если иконок много то спрайт будет слишком толстый, если на странице используются 1-5 иконок, и ради них тянуть спрайт со остальными 70 иконками… так себе решение.
А чтобы заставить это работать в осле, надо js еще подключать, который будет брать иконку из спрайта и инжектить в html. Но если осел не нужен и класть на размер спрайта, то вполне неплохое решение)
Никак не могу понять, как идет разделение на верстальщика для фреймворка и разработчика на фреймворке. Интересно было бы почитать про весь процесс такой разработки на каком-нибудь примере. Я видел вакансии по типу верстальщик реакт, ангуляр но никак не мог понять в чем выгода такого разделения?
Честно говоря слабо представляю как может сломаться вёрстка после добавления логики
Сеньор верстальщик сверстал макет по мокам и протестил его, но он не учел, что реальные данные там окажутся куда больше чем в моках, и, например, появился скролл, в результате чего поехала верстка. Выявили косяки в других браузерах, на других разрешениях(как бы не тестил сеньор верстальщик — это неизбежно).
Это кстати справедливо не только для фонт фреймворков, но так же эта проблема актуальна для различных CMS и бекенд фреймворков
При понимании того, как работают блоки в целом и начилии базового понимания JS, да и уж с минимальным изучением конкретного фреймворка, у верстальщика не составляет проблем сразу делать как надо.
Так в итоге это верстальщик или уже фронтендер? Зачем пускать туда человека, который имеет базовые знания и может делать только какую-то малую часть(возможно даже криво и неэффективно), в итоге же может получится так, что опытному разработчику придется все переделывать за верстальщиком с нуля. Двойная работа на лицо.
У вас в проекте, если меняется логика в приложении, или набор данных который надо визулизировать становится другим, кто правит шаблон, верстальщик или фронтендер, или у вас нет фронтендеров и все делает сеньор верстальщик? Не получается ли у так, что верстальщик говорит что его код работает, а после добавления логики все сломалось и это не его косяк? Как вы определяете кого наказывать, а кого поощрять?
У реакта нет шаблонизатора. Верстальщик должен понимать сам реакт, что бы написать код компонента.
Для ангуляра, вуя и всех современных фреймворков отдельно верстать шаблоны — это лишний геморой.
Как у вас выстроен этот процесс? Верстальщик тратит 30 часов на один компонент, а потом фронтендер берет его код, тратит еще 30 часов, разбивает его до неузноваемости навешивая туда логику? Как потом верстальщик исправляет косяки верстки в итоговом результате, лезет в код приложения и навешивает заплатки в css?
А пробовали обновлять инструменты, которые используете, проект стартует? Не задумывались о том, что когда придет время переходить на более свежие версии, то придется много чего переписать, выкинуть и перенастроить окружение полностью?
Кто-нибудь находил аналогичный стабильный продукт (не облачное решение)?
В статье еще используются css переменные, которые так же не везде поддерживаются. Это как бы тоже уже не кроссбраузерно. Осла списывать рановато
При таком подходе мне не понятно, зачем вообще делать
<use xlink:href="#icon-coffee" href="#icon-coffee" />Если можно сразу вставить svg код в нужное место, и без извращений поменять цвет, рамер… да что угодно. Это железно работает везде.А чтобы заставить это работать в осле, надо js еще подключать, который будет брать иконку из спрайта и инжектить в html. Но если осел не нужен и класть на размер спрайта, то вполне неплохое решение)
Как у вас организован процесс совместной разработки при таком разделении?
Это что за свойства такие?
Сеньор верстальщик сверстал макет по мокам и протестил его, но он не учел, что реальные данные там окажутся куда больше чем в моках, и, например, появился скролл, в результате чего поехала верстка. Выявили косяки в других браузерах, на других разрешениях(как бы не тестил сеньор верстальщик — это неизбежно).
Это кстати справедливо не только для фонт фреймворков, но так же эта проблема актуальна для различных CMS и бекенд фреймворков
Не думаю, что у тех кто понимает что такое JSX, повернется язык назвать это шаблонизатором в каком-то виде.
так это и называется шаблонные строки
Так в итоге это верстальщик или уже фронтендер? Зачем пускать туда человека, который имеет базовые знания и может делать только какую-то малую часть(возможно даже криво и неэффективно), в итоге же может получится так, что опытному разработчику придется все переделывать за верстальщиком с нуля. Двойная работа на лицо.
У вас в проекте, если меняется логика в приложении, или набор данных который надо визулизировать становится другим, кто правит шаблон, верстальщик или фронтендер, или у вас нет фронтендеров и все делает сеньор верстальщик? Не получается ли у так, что верстальщик говорит что его код работает, а после добавления логики все сломалось и это не его косяк? Как вы определяете кого наказывать, а кого поощрять?
Для ангуляра, вуя и всех современных фреймворков отдельно верстать шаблоны — это лишний геморой.
Как у вас выстроен этот процесс? Верстальщик тратит 30 часов на один компонент, а потом фронтендер берет его код, тратит еще 30 часов, разбивает его до неузноваемости навешивая туда логику? Как потом верстальщик исправляет косяки верстки в итоговом результате, лезет в код приложения и навешивает заплатки в css?
А вы собираетесь обновлять окружение? Или этот проект отработает отведенное ему время, а потом просто перепишите все с нуля?