Когда же этот min-width закончится уже?
В нормальных браузерах поддерживается ResizeObserver (а для остальных есть iframe-хак). С его помощью легко написать свой вывод адаптивных картинок, который будет основываться на размерах доступного контейнера, а не window.
Есть и готовое из коробки, например, github.com/marcj/css-element-queries.
У меня 4 детей, и основное, что я понял — каждый ребенок — индивидуальность. Одни болеют, другие нет, одни самостоятельные с рождения, а другим требуется поддержка. Это — моя поддержка, помощь с фокусировкой внимания.
Против прокрастинации мне лично очень помогает таймер (hubstaff или upwork). И все контракты у меня с почасовой оплатой. Если таймер запущен, не позволяешь себе никаких лишних вкладок, таймер делает скриншоты, некрасиво, когда на скриншоте вдруг фейсбук с личной перепиской.
Согласен, пример собран из не английского исходника. Почему-то в процессе kabinet в cabinet превратился… В проектах, над которыми работаю, скорость ввода не сильно важна. На первом месте — мощность отображения, наложение любых календарей друг на друга (например, календарь учителя поверх календаря activities), потом подсветка assignments и workshifts других учителей, чтобы было видно, когда данному можно проставить перерыв, на какие блоки его еще можно записать итд.
Поддерживаю, у меня с crossover пару лет назад не сложилось из-за 40-а часов. Индустрия быстро развивается, чтобы оставаться в теме одного основного рабочего стека едва ли достаточно. Со своими проектами и опенсурсом на работу остается часов 5. Upwork кстати хорошо развивает, если не бояться брать небольшие проекты немного вне своих основных инструментов.
Зачем в модификаторе повторять всю цепочку названия? Моя верстка в общем следует бэму, только все модификаторы, и только они, начинаются с `-` т.е. вместо
В статье вроде написано про серверный рендеринг, но подано это как-то странно, будто бы главным смыслом SSR является подготовка статики для выкладывания ее на CDN через nuxt generate.
На самом деле, SSR в nuxt — это попытка наконец-таки делать индексируемые динамические сайты (single page applications) + попытка ускорить первоначальную загрузку этих самых сайтов. Грубо говоря, вместо того, чтобы грузить заглушку, которая после инициализации подтянет данные через ajax, эти данные будут подтянуты nuxt-ом на сервере через node, отрендерены и отданы сразу же в шаблоне.
Насколько попытка удачная — покажет время, обещают скоро выкатить 1.0, пока что все это изрядно глючит, а раз так, едва ли можно положиться на nuxt в продакшене, где эти оптимизации имеют смысл.
Наверное, в vuex возможно хранить вообще все переменные приложения, но, на мой взгляд, это — неоптимальный вариант. У меня в vuex хранится только критический минимум важных данных, а компоненты имеют свои собственные локальные данные и события. Они более независимы, лучше живут сами по себе.
Можно же вообще все в одном компоненте написать.
Простой пример — вызов модального окошка с настройками, которое вызывается из компонента каждого элемента списка и еще откуда-нибудь.
На мой взгляд, между глобальными переменными и глобальной шиной событий есть большая разница. По сути, все redux-mobx-vuex это попытки более безопасного использования глобальных переменных. Как только приложение разбивается на локальные компоненты, над ними всегда висит что-то глобальное, что их связывает. EventEmitter — еще один способ связи, довольно безопасный.
Проблема масшабирования — главное, с чем нужно разобраться в игре. Поначалу не знаешь, сколько заводов проволоки нужно на сколько заводов микросхем, итд. Но даже когда знаешь все пропорции, зачастую оказывается, что хочешь удвоить производство, а места на заводы/конвееры уже не хватает. Блоки заводов приходится выносить, и все становится слишком сложным.
Обычно строят центральную шину с основными матариалами, а заводы — ортогонально шине, тогда ряд заводов можно продолжать неограничено.
Но я сам предпочитаю треугольную расширяющуюся шину. Один конвеер для одного продукта без смешивания. Идея такая:
Слева направо идут ресурсы, заводы строятся только вверх, ленты конвеера идут 2 через 2 чтобы строить подземные переходы. Отделяешь нужные ветки ресурсов, ведешь наверх, строишь заводы один над другим, результат спускаешь вниз в новую линию.
Почти все ресурсы строятся не более чем из 4-х компонентов.
Для самого сложного случая, 4-х компонентов, схема может выглядеть так:
Отличный материал, спасибо. Особенно согласен в плане взаимодействия с базой.
Буду ссылаться вместо того, чтобы каждый раз объяснять, почему до сих пор пишу все запросы руками.
В плане базы я бы сделал акцент на то, что большинство систем работают в основном на чтение (1 запись на 100 чтений). Поэтому простота чтения должна быть обеспечена в первую очередь. Академические нормальные формы, например, отношения many-to-many в отдельных таблицах, должны быть продуманы, нужны ли они вообще в каждом конкретном случае.
5 копеек про фронт: я бы выделил 3 периода: до jquery, с jquery, с mvvm (knockout/angular/react/vue). Если система не в 3-ем периоде и хочет развиваться, то нужно переходить. Внутри mvvm переход едва ли оправдан — несмотря на различную внутреннюю логику, нет ничего на angular/react, чего нельзя написать на старичке knockout в тех же строчках кода и той же сложности. Новеньким я бы советовал vue.js как последователя, который включил все лучшее от предшественников.
Фанаты реакт хвалятся виртуальным dom-деревом — мол самые затратные операции — операции с dom, поэтому прослойка, которая фильтрует изменения dom, делает реакт очень быстрым. Однако реакт тоже прекрасно вешается, если не думать. А если думать, то любая универсальная прослойка будет медленнее, чем нативный специализированный код, который не делает ничего лишнего.
В нормальных браузерах поддерживается ResizeObserver (а для остальных есть iframe-хак). С его помощью легко написать свой вывод адаптивных картинок, который будет основываться на размерах доступного контейнера, а не window.
Есть и готовое из коробки, например, github.com/marcj/css-element-queries.
На самом деле, SSR в nuxt — это попытка наконец-таки делать индексируемые динамические сайты (single page applications) + попытка ускорить первоначальную загрузку этих самых сайтов. Грубо говоря, вместо того, чтобы грузить заглушку, которая после инициализации подтянет данные через ajax, эти данные будут подтянуты nuxt-ом на сервере через node, отрендерены и отданы сразу же в шаблоне.
Насколько попытка удачная — покажет время, обещают скоро выкатить 1.0, пока что все это изрядно глючит, а раз так, едва ли можно положиться на nuxt в продакшене, где эти оптимизации имеют смысл.
Можно же вообще все в одном компоненте написать.
Простой пример — вызов модального окошка с настройками, которое вызывается из компонента каждого элемента списка и еще откуда-нибудь.
Обычно строят центральную шину с основными матариалами, а заводы — ортогонально шине, тогда ряд заводов можно продолжать неограничено.
Но я сам предпочитаю треугольную расширяющуюся шину. Один конвеер для одного продукта без смешивания. Идея такая:
Слева направо идут ресурсы, заводы строятся только вверх, ленты конвеера идут 2 через 2 чтобы строить подземные переходы. Отделяешь нужные ветки ресурсов, ведешь наверх, строишь заводы один над другим, результат спускаешь вниз в новую линию.
Почти все ресурсы строятся не более чем из 4-х компонентов.
Для самого сложного случая, 4-х компонентов, схема может выглядеть так:
Ну и полная картинка одной из баз — http://booger.ru/data/2017_07_04/FullSize.jpg
Игрушка правда уже не новая, сам играл год назад.
Буду ссылаться вместо того, чтобы каждый раз объяснять, почему до сих пор пишу все запросы руками.
В плане базы я бы сделал акцент на то, что большинство систем работают в основном на чтение (1 запись на 100 чтений). Поэтому простота чтения должна быть обеспечена в первую очередь. Академические нормальные формы, например, отношения many-to-many в отдельных таблицах, должны быть продуманы, нужны ли они вообще в каждом конкретном случае.
5 копеек про фронт: я бы выделил 3 периода: до jquery, с jquery, с mvvm (knockout/angular/react/vue). Если система не в 3-ем периоде и хочет развиваться, то нужно переходить. Внутри mvvm переход едва ли оправдан — несмотря на различную внутреннюю логику, нет ничего на angular/react, чего нельзя написать на старичке knockout в тех же строчках кода и той же сложности. Новеньким я бы советовал vue.js как последователя, который включил все лучшее от предшественников.
Фанаты реакт хвалятся виртуальным dom-деревом — мол самые затратные операции — операции с dom, поэтому прослойка, которая фильтрует изменения dom, делает реакт очень быстрым. Однако реакт тоже прекрасно вешается, если не думать. А если думать, то любая универсальная прослойка будет медленнее, чем нативный специализированный код, который не делает ничего лишнего.