Вы смотрели на веб-компоненты и пользовательские элементы в частности? Статью читал по диагонали, но мне кажется это именно то, что вам нужно, и проблем с наследованием когда отсутствует element.style там нет.
В моих предыдущих статьях есть сравнение некоторых аспектов и существенные отличия в подходах по сравнению с другими мейнстримовыми фреймворками. Если кратко, то то, что в других фреймворках требует код и кучу централизованной конфигурации здесь либо работает совсем без конфигурации (используются вменяемые настройки по умолчанию, которые можно при необходимости переопределить) либо использует распределенную и чаще всего декларативную конфигурацию.
Для быстрого погружения можно посмотреть несколько скринкастов, больше записать пока руки не доходят: https://www.youtube.com/playlist?list=PLVUA3QJ02XIiKEzpD4dxoCENgzzJyNEnH
Скринкасты могут быть слегка устаревшими, но не смотря на это они всё равно полезны, просмотрев их вы оцените какой подход используется и сможете оценить, нравится ли вам такое или нет.
x-tags, к примеру, тоже 20 КБ, а в браузерах что поддерживают нативно будет вообще 0 (как не крути, таких подавляющее большинство).
При этом будет быстрее и проще, ибо используются нативные интерфейсы.
React нативно вообще нигде не поддерживается и не будет.
Уровень абстракции не хуже. При использовании Polymer есть и биндинги, и возможности рендерить кучу элементов из массива по шаблону, включая реакцию на изменение состояния (в новом проекте я использую Redux вместе с веб-компонентами), и декларативные подписки на события, и многое другое.
Интегрировать это в любой фреймворк весьма просто, ибо там нет ничего кроме родных браузерных событий и свойств элементов. Если ваш фреймворк не может с этим интегрироваться, то стоит подумать о том, чтобы выбросить его в окно.
В противовес попробуйте интегрировать один React компонент в не-React проект — у вас и оверхед React будет похуже оверхеда полифиллов + Polymer, да и без трехэтажной системы сборки не обойтись. А веб-компоненты просто работают. В совершенно любом проекте, так же как в любом проекте работает <div>.
Мне всегда казалось что использование Web Components единственное решение, которое на 100% совместимо с чем угодно другим. Зачем ещё кучу всего сверху?
На самом деле зависит от сложности проблемы и прямоты рук. Я вот некоторые мелочи в коде и правки конфигурации не раз исправлял и апстримил после этого.
Bower/NPM используются и так, а вот Webpack зачем? Node.js на сервере может не быть, работает он медленнее, для интеграции в проект (таким образом, как это описано в статье) всё равно придется написать кучу кода. А так никаких императивных конфигураций не нужно и всё шустро работает. А если Webpack для чего-то нужен, то его можно несколькими строчками интегрировать как готовый сторонний сервис вместо того, чтобы требовать на уровне фреймворка.
может мне вообще не понадобится оттуда ничего кроме одного куска — в вашем случае все равно подключится то что система посчитает нужным.
Советов несколько:
делите на самостоятельные куски, чтобы подключать только нужное
если это JS — выделяйте в AMD модуль и грузите только его (об этом будет отдельный пост)
если первые два варианта не подходят — есть вероятность, что лишнего кода не так много и с этим можно жить
Если совсем кастомная ситуация — вы всегда можете дополнить встроенную функциональность фреймворка и интегрировать туда в том числе gulp, если контролируете окружение. Фреймворк не покрывает 100% ситуаций самостоятельно, но оставляет возможности интеграции для покрытия 100% ситуаций при необходимости. Нужно следить за балансом предоставляемой из коробки функциональности.
Вдруг я захочу вместо скрипта от модуля использовать свой?
Вот здесь не совсем понятно что имеется ввиду. Модуль это самостоятельная единица, перезаписывать отдельные файлы тоже в теории можно (подписаться на события установки/обновления модулей и перезаписывать нужный файл поверх, либо подписаться на упомянутое в статье событие и редактировать путь к исходному файлу в маппинге ресурсов), но это уже как-то совсем дико. Какой сценарий имеется ввиду?
А если зависимость необязательная? К примеру, WYSIWYG редактор — на базовую функциональность не влияет, может как быть, так и отсутствовать. Криво как-то вписывать это вручную в gulp-задачу, да ещё с проверками на наличие файлов.
В том-то и преимущество в CleverStyle Framework — вы не прописываете вручную ничего для использования. Разработчик модуля объявляет всё декларативно во время разработки, после чего достаточно установить модуль, и на основании декларативной конфигурации нужное странице будет подключено и закэшировано как положено.
мы все еще про зависимости фронтэнда или про модули в вашей системе? Если модули в вашей системе — то что-то тут нечисто
Зависимости между модулями используются и для бекенда, и для фронтенда, так что, полагаю, ответ зависимости фронтенда. В примере выше я имел ввиду именно его.
А как там с зависимостями, нужно в повторять подключение множества файлов раз за разом?
Вот есть у меня один модуль, в котором нужно загружать котиков, и второй модуль, который непосредственно реализует загрузку файлов в общем виде. В каждом из модулей есть набор CSS/JS/HTML файлов, но перед тем как грузить котиков мне нужен сам функционал загрузки.
В моем случае это будут два модуля, каждый из который имеет в простейшем виде следующее:
gulpfile.js не подходит по идеологическим причинам — CleverStyle Framework не требует на сервере ничего кроме PHP, к тому же все модули опциональные, они в репозитории, но не обязательно в комплекте.
Использование только PHP позволяет делать удобные интеграции всего вместе в том числе с клиентского интерфейса, когда нет доступа к CLI в принципе. Например, установка Bower/NPM пакетов с помощью Composer плагина прямо из админки с интерактивным прогрессом, хотя для самого Composer в обычном режиме нужен доступ к CLI, а плагин должен быть установлен глобально.
Я с Elixir не работал, но исходя из того, что это надстройка над Gulp — его можно использовать и с CleverStyle Framework без особых сложностей. Можно либо складывать артефакты туда, откуда их автоматически подхватит фреймворк, либо написать кастомную небольшую интеграцию с помощью обработчиков упомянутых в статье событий.
Я пытался сделать работу со статикой максимально декларативной, то есть вы указываете какой файл (или группу файлов, которая в продакшене конкатенируется в один файл) нужен на какой странице, а обо всём остальном, включая версии и зависимости побеспокоится фреймворк. То есть вам никогда не нужно писать нечто подобное:
Это скорее проблема реализации, чем подхода. К примеру, у вас вместо смс может быть отправка сообщения в Tox на заранее согласованный профиль. Суть остается той же, но перехват сообщения без доступа к устройству с профилем Tox становится невозможным.
Для её получения (при условии надежности сети) нужен телефон. Иначе можно сказать что телефон можно хакнуть удаленно и получить доступ к приложению, генерирующему токены, то есть телефон опять перестал быть вторым фактором. Но это всё не проблемы сервиса, использующего двухфакторную аутентификацию. Это всё ещё совершенно другой способ подтвердить что вы это вы с точки зрения сервиса. Сервис генерирует одноразовый токен и отправляет по смс. То, что канал доставки скомпрометирован на вашей стороне не проблема сервиса.
Это фактор той же категории, того же типа, что и основной адрес. То есть он не третий, он не является обязательным, он альтернативный первому, следовательно, уменьшает общую безопасность, поскольку есть альтернатива — взломать один из двух почтовых ящиков на выбор. То есть можно выбрать более слабое звено. Если это два ящика на разных серверах с разными паролями и разными телефонами — то безопасность может быть аналогичной, но точно не выше.
люди и этот резервный адрес привязывают к тому же телефону
Это явно проблема в другой плоскости, с этим технологии ничего не поделают.
Если вы хотите большей надежности, не привязывайте телефон к восстановлению пароля, так как телефон у вас увести легче, чем подобрать пароль.
It depends, но на мобильную сеть (звонки, смс) я бы и правда не надеялся. Жаль, что у тех же Namecheap только смс и поддерживаются.
Хак мобильной сети или ОС телефона это надежность второго фактора, она никак не влияет на первый (если восстановление пароля проходит через email, а доступ к email у вас через тот же телефон и смс то кто тут вам доктор). Статья же в заголовке этого не декларирует, поэтому я переживаю что люди начнут отказываться от второго фактора "потому что я это где-то читал/слышал".
Нет, смс это фактор "имею" (имею телефон). Этот код каждый раз разный, вы его наперед не знаете и подобрать не можете не имея в руках телефон, на который приходит код (уязвимости мобильных сетей здесь не учитываем, смс только один из способов).
Вы смотрели на веб-компоненты и пользовательские элементы в частности? Статью читал по диагонали, но мне кажется это именно то, что вам нужно, и проблем с наследованием когда отсутствует
element.styleтам нет.В моих предыдущих статьях есть сравнение некоторых аспектов и существенные отличия в подходах по сравнению с другими мейнстримовыми фреймворками. Если кратко, то то, что в других фреймворках требует код и кучу централизованной конфигурации здесь либо работает совсем без конфигурации (используются вменяемые настройки по умолчанию, которые можно при необходимости переопределить) либо использует распределенную и чаще всего декларативную конфигурацию.
Для быстрого погружения можно посмотреть несколько скринкастов, больше записать пока руки не доходят: https://www.youtube.com/playlist?list=PLVUA3QJ02XIiKEzpD4dxoCENgzzJyNEnH
Скринкасты могут быть слегка устаревшими, но не смотря на это они всё равно полезны, просмотрев их вы оцените какой подход используется и сможете оценить, нравится ли вам такое или нет.
Больше трех лет прошло, тут не пароль менять нужно, а бежать из сервиса как можно быстрее.
За такие советы нужно банить доступ к интернету
x-tags, к примеру, тоже 20 КБ, а в браузерах что поддерживают нативно будет вообще 0 (как не крути, таких подавляющее большинство).
При этом будет быстрее и проще, ибо используются нативные интерфейсы.
React нативно вообще нигде не поддерживается и не будет.
Уровень абстракции не хуже. При использовании Polymer есть и биндинги, и возможности рендерить кучу элементов из массива по шаблону, включая реакцию на изменение состояния (в новом проекте я использую Redux вместе с веб-компонентами), и декларативные подписки на события, и многое другое.
Интегрировать это в любой фреймворк весьма просто, ибо там нет ничего кроме родных браузерных событий и свойств элементов. Если ваш фреймворк не может с этим интегрироваться, то стоит подумать о том, чтобы выбросить его в окно.
В противовес попробуйте интегрировать один React компонент в не-React проект — у вас и оверхед React будет похуже оверхеда полифиллов + Polymer, да и без трехэтажной системы сборки не обойтись. А веб-компоненты просто работают. В совершенно любом проекте, так же как в любом проекте работает
<div>.Мне всегда казалось что использование Web Components единственное решение, которое на 100% совместимо с чем угодно другим. Зачем ещё кучу всего сверху?
На самом деле зависит от сложности проблемы и прямоты рук. Я вот некоторые мелочи в коде и правки конфигурации не раз исправлял и апстримил после этого.
Bower/NPM используются и так, а вот Webpack зачем? Node.js на сервере может не быть, работает он медленнее, для интеграции в проект (таким образом, как это описано в статье) всё равно придется написать кучу кода. А так никаких императивных конфигураций не нужно и всё шустро работает. А если Webpack для чего-то нужен, то его можно несколькими строчками интегрировать как готовый сторонний сервис вместо того, чтобы требовать на уровне фреймворка.
Советов несколько:
Если совсем кастомная ситуация — вы всегда можете дополнить встроенную функциональность фреймворка и интегрировать туда в том числе gulp, если контролируете окружение. Фреймворк не покрывает 100% ситуаций самостоятельно, но оставляет возможности интеграции для покрытия 100% ситуаций при необходимости. Нужно следить за балансом предоставляемой из коробки функциональности.
Вот здесь не совсем понятно что имеется ввиду. Модуль это самостоятельная единица, перезаписывать отдельные файлы тоже в теории можно (подписаться на события установки/обновления модулей и перезаписывать нужный файл поверх, либо подписаться на упомянутое в статье событие и редактировать путь к исходному файлу в маппинге ресурсов), но это уже как-то совсем дико. Какой сценарий имеется ввиду?
А если зависимость необязательная? К примеру, WYSIWYG редактор — на базовую функциональность не влияет, может как быть, так и отсутствовать. Криво как-то вписывать это вручную в gulp-задачу, да ещё с проверками на наличие файлов.
В том-то и преимущество в CleverStyle Framework — вы не прописываете вручную ничего для использования. Разработчик модуля объявляет всё декларативно во время разработки, после чего достаточно установить модуль, и на основании декларативной конфигурации нужное странице будет подключено и закэшировано как положено.
Зависимости между модулями используются и для бекенда, и для фронтенда, так что, полагаю, ответ зависимости фронтенда. В примере выше я имел ввиду именно его.
А как там с зависимостями, нужно в повторять подключение множества файлов раз за разом?
Вот есть у меня один модуль, в котором нужно загружать котиков, и второй модуль, который непосредственно реализует загрузку файлов в общем виде. В каждом из модулей есть набор CSS/JS/HTML файлов, но перед тем как грузить котиков мне нужен сам функционал загрузки.
В моем случае это будут два модуля, каждый из который имеет в простейшем виде следующее:
gulpfile.js не подходит по идеологическим причинам — CleverStyle Framework не требует на сервере ничего кроме PHP, к тому же все модули опциональные, они в репозитории, но не обязательно в комплекте.
Использование только PHP позволяет делать удобные интеграции всего вместе в том числе с клиентского интерфейса, когда нет доступа к CLI в принципе. Например, установка Bower/NPM пакетов с помощью Composer плагина прямо из админки с интерактивным прогрессом, хотя для самого Composer в обычном режиме нужен доступ к CLI, а плагин должен быть установлен глобально.
Я с Elixir не работал, но исходя из того, что это надстройка над Gulp — его можно использовать и с CleverStyle Framework без особых сложностей. Можно либо складывать артефакты туда, откуда их автоматически подхватит фреймворк, либо написать кастомную небольшую интеграцию с помощью обработчиков упомянутых в статье событий.
Я пытался сделать работу со статикой максимально декларативной, то есть вы указываете какой файл (или группу файлов, которая в продакшене конкатенируется в один файл) нужен на какой странице, а обо всём остальном, включая версии и зависимости побеспокоится фреймворк. То есть вам никогда не нужно писать нечто подобное:
Это скорее проблема реализации, чем подхода. К примеру, у вас вместо смс может быть отправка сообщения в Tox на заранее согласованный профиль. Суть остается той же, но перехват сообщения без доступа к устройству с профилем Tox становится невозможным.
Для её получения (при условии надежности сети) нужен телефон. Иначе можно сказать что телефон можно хакнуть удаленно и получить доступ к приложению, генерирующему токены, то есть телефон опять перестал быть вторым фактором. Но это всё не проблемы сервиса, использующего двухфакторную аутентификацию. Это всё ещё совершенно другой способ подтвердить что вы это вы с точки зрения сервиса. Сервис генерирует одноразовый токен и отправляет по смс. То, что канал доставки скомпрометирован на вашей стороне не проблема сервиса.
Первая часть отвечает на восстановление.
В том то и дело что нет.
Это фактор той же категории, того же типа, что и основной адрес. То есть он не третий, он не является обязательным, он альтернативный первому, следовательно, уменьшает общую безопасность, поскольку есть альтернатива — взломать один из двух почтовых ящиков на выбор. То есть можно выбрать более слабое звено. Если это два ящика на разных серверах с разными паролями и разными телефонами — то безопасность может быть аналогичной, но точно не выше.
Это явно проблема в другой плоскости, с этим технологии ничего не поделают.
It depends, но на мобильную сеть (звонки, смс) я бы и правда не надеялся. Жаль, что у тех же Namecheap только смс и поддерживаются.
Хак мобильной сети или ОС телефона это надежность второго фактора, она никак не влияет на первый (если восстановление пароля проходит через email, а доступ к email у вас через тот же телефон и смс то кто тут вам доктор). Статья же в заголовке этого не декларирует, поэтому я переживаю что люди начнут отказываться от второго фактора "потому что я это где-то читал/слышал".
Нет, смс это фактор "имею" (имею телефон). Этот код каждый раз разный, вы его наперед не знаете и подобрать не можете не имея в руках телефон, на который приходит код (уязвимости мобильных сетей здесь не учитываем, смс только один из способов).