Отличная статья, содержит ответы на ряд вопросов которые меня давно волновали, как по мне самая ценная мысль в том, что какая бы не была умная база, лучше самому выполнить разделение таблиц на метаданные и данные там где это явно не помешает
У меня на проекте фронтенд на микросервисах,
есть сервис который занимаеться раскидыванием запросов прокси на .net (у каждой части приложение свой publicPath), каждый кусок приложения это собранный webpack-ом проект с праметром library,
все общие куски выносим в npm пакеты.
В результате имеем на странице множестов webpack-рантаймов, все зависимости имеют свой namespace, есть центральное shell приложение которое при необходимости загружает нужные ему куски приложения (модули записываю свой роутинг в глобальную переменную).
При необходимости можно не включать общие зависимости в сборку модулей (webpack параметр externals).
В общем iframe — не лучший вариант :)
Давно слежу за развитием этого проекта, ребята реально молодцы, видно что вкладывают душу, качество компонентов отличное. Планирую попробовать для небольшой админки
в прошлом году ставил 2 импланта, тоже очень боялся, процедура действительно безболезненная, в костных тканях нет ничего что давало было хоть какие то ощущения, главное с этим не тянуть а то потом потребуються доп процедуры :)
При сборке анализируются компоненты которые необходимо включить в продакшен билд, простенькое приложение с одним компонентом и самым базовым биндингом, у меня занимало порядка 2кб
Про will-change свойство, написано не совсем правильно, насколько я понимаю, will-change: transform; подсказывает браузеру, что элемент будет двигаться, и ему стоит подготовить для его отрисовки отдельный слой. И мне не совсем понятно, почему в параметрах указан именно transform, ведь по идее как раз transfrom не происходит? Хоть могу ошибаться, и тогда получается, что браузер для скрола использует transform?
Что если в качестве параметра для will-change указать opacity к примеру?
Магия тут в том, что после того как python выбросит Exception с ошибкой "Я не могу подифицировать tuple", мы можешь распечатать этот самый tuple и увидить что в массив внутри него все же был добавлен элемент.
Есть у меня сомнения по поводу «самый быстрый»
есть сервис который занимаеться раскидыванием запросов прокси на .net (у каждой части приложение свой publicPath), каждый кусок приложения это собранный webpack-ом проект с праметром library,
все общие куски выносим в npm пакеты.
В результате имеем на странице множестов webpack-рантаймов, все зависимости имеют свой namespace, есть центральное shell приложение которое при необходимости загружает нужные ему куски приложения (модули записываю свой роутинг в глобальную переменную).
При необходимости можно не включать общие зависимости в сборку модулей (webpack параметр externals).
В общем iframe — не лучший вариант :)
Что если в качестве параметра для will-change указать opacity к примеру?
a = ([1,2,3], )
a[0].append(4)
print a
a[0] += [5]
// exception
print a