Отлаживаю ноду в Visual Studio. Там есть шаблон проекта с TypeScript, запускаешь по F5 и получаешь полноценную отладку с бряками, пошаговым исполнением и всеми остальными прелестями.
Ответа на вопрос "в чем сила" так и не прочитал. Сказано что 1) Redux сложный 2) неимоверно крутой (без объяснений) 3) никто его не понимает 4) у него скудный неудобный API 5) был придуман time-travel и всякий мидл-вар в нем удобен. В чем сила так и не раскрыто.
Если мне понадобится добавить специальные отступы для иконок панели, я естественно добавлю класс left-panel и пропишу его там. Классы size-16 и т.д. всегда строго содержат размер и ничего больше. В этом суть атомарности. Просто, чаще всего не нужно ничего, кроме иконки и размера.
Иногда атомарный css очень в тему. Допустим, есть классы иконок ico-accept, ico-decline… Чтобы добавить иконку в коде просто делаешь блок с этим классом. Но в каждом случае еще нужно задать размер иконки. Приходится добавлять еще класс, селектор в стили, и там прописывать размер. Либо сделать проще — один раз определить набор классов size-16, size-18, size-20… и тогда иконки можно полностью определять в html.
Ужасно интересно, приведите примеры шероховатостей. Я тоже использую флексы, но обычно для не очень сложных вещей. Кроме min-width и flex-basis вроде пока явных сюрпризов не встречал.
В основном шаманство с флексами возникает от непонимания флексов. Они действительно не такие простые, как пишут во всяких "полных руководствах по флексбокс" (например, там обычно не пишут всего того, что в этой статье). Есть конечно и баги в разных браузерах, но их не так много, с этим можно жить. Поэтому, думаю некорректно сравнивать флексы с тем что было раньше.
Что autoloader в php, что агностик-модули, все заменяют import строгими правилами именования сущностей. То есть, конфликты имен в глобальной области видимости решаются конвенциональным путем. Проблема такого подхода очевидна — длинные имена и сложность заставить всех писать уникальные имена в правильном виде.
Про Redux… Там ведь не только конфликты имен могут быть, но совершенно неконтролируемое сцепление различных частей приложения, к тому же без поддержки соотв. тулинга. Мы (императивные программисты) инкапсулируем еще со времен модульного программирования, но функциональщики вообще не от мира сего ^_^
А про писанину, об этом как раз моя статья. Мне удалось уменьшить ее количество вплоть до одной-двух строчек import.
Я смотрел агностик модули. Может это и круто, но import это стандарт, лучше все-таки придерживаться стандартных средств. Глобальная область видимости уже была, и от нее решили отказаться по многим причинам.
А еще может быть так, что в компании уже куплена VisualStudio, которая во всем всех устраивает, в ней настроены все дев-процессы (сборка, отладка и т.д.) и покупать еще отдельно другую IDE только из-за того что она умеет дописывать import и в результате получить гемор с перенастройкой процессов и переучиванием разработчиков — да никто не будет таким заниматься...
Вот, вот, "комбинаторный взрыв", "значение могло устареть" и еще куча страшных слов в той статье и комментариях к ней. По-моему, задача слишком сложная, что бы ее решать вот так автоматически.
Вы о чем конкретно? Опишите подробнее свою мысль.
Отлаживаю ноду в Visual Studio. Там есть шаблон проекта с TypeScript, запускаешь по F5 и получаешь полноценную отладку с бряками, пошаговым исполнением и всеми остальными прелестями.
AngularJS называют Angular 1. Тот что 2 называют просто Angular. Ну и вообще, Angular сейчас ловит хайпа куда меньше чем React. У Вас как бы наоборот.
Про AngularJS в 2017-том писать… Как буд-то статья была написана несколько лет назад.
Подразумевается, что заменят size-16 на size-20 в html. Если кто-то в классе size-16 напишет 20px, ему можно смело отрывать руки: )
Очевидный минус в том, что size-16 содержит набор свойств:
Указывать каждый раз 3 свойства с дублирующимися значениями громоздко.
Ну еще тулинг.
Ответа на вопрос "в чем сила" так и не прочитал. Сказано что 1) Redux сложный 2) неимоверно крутой (без объяснений) 3) никто его не понимает 4) у него скудный неудобный API 5) был придуман time-travel и всякий мидл-вар в нем удобен. В чем сила так и не раскрыто.
Только хотел написать — да, группировка частей схемы. Выделяешь кусок связанных блоков, группируешь, и получается один блок с общим названием.
Если мне понадобится добавить специальные отступы для иконок панели, я естественно добавлю класс left-panel и пропишу его там. Классы size-16 и т.д. всегда строго содержат размер и ничего больше. В этом суть атомарности. Просто, чаще всего не нужно ничего, кроме иконки и размера.
На простых примерах выглядит вдохновляюще, но как посмотришь на сложные схемы — уж лучше какой-то текстовый формат...
Иногда атомарный css очень в тему. Допустим, есть классы иконок ico-accept, ico-decline… Чтобы добавить иконку в коде просто делаешь блок с этим классом. Но в каждом случае еще нужно задать размер иконки. Приходится добавлять еще класс, селектор в стили, и там прописывать размер. Либо сделать проще — один раз определить набор классов size-16, size-18, size-20… и тогда иконки можно полностью определять в html.
Очень упрощает жизнь.
Пробовал кто с TypeScript работать?
Ужасно интересно, приведите примеры шероховатостей. Я тоже использую флексы, но обычно для не очень сложных вещей. Кроме min-width и flex-basis вроде пока явных сюрпризов не встречал.
Слово "зажатый" режет слух. Почему не "сжатый"?
В основном шаманство с флексами возникает от непонимания флексов. Они действительно не такие простые, как пишут во всяких "полных руководствах по флексбокс" (например, там обычно не пишут всего того, что в этой статье). Есть конечно и баги в разных браузерах, но их не так много, с этим можно жить. Поэтому, думаю некорректно сравнивать флексы с тем что было раньше.
Что autoloader в php, что агностик-модули, все заменяют import строгими правилами именования сущностей. То есть, конфликты имен в глобальной области видимости решаются конвенциональным путем. Проблема такого подхода очевидна — длинные имена и сложность заставить всех писать уникальные имена в правильном виде.
Про Redux… Там ведь не только конфликты имен могут быть, но совершенно неконтролируемое сцепление различных частей приложения, к тому же без поддержки соотв. тулинга. Мы (императивные программисты) инкапсулируем еще со времен модульного программирования, но функциональщики вообще не от мира сего ^_^
А про писанину, об этом как раз моя статья. Мне удалось уменьшить ее количество вплоть до одной-двух строчек import.
Я смотрел агностик модули. Может это и круто, но import это стандарт, лучше все-таки придерживаться стандартных средств. Глобальная область видимости уже была, и от нее решили отказаться по многим причинам.
А еще может быть так, что в компании уже куплена VisualStudio, которая во всем всех устраивает, в ней настроены все дев-процессы (сборка, отладка и т.д.) и покупать еще отдельно другую IDE только из-за того что она умеет дописывать import и в результате получить гемор с перенастройкой процессов и переучиванием разработчиков — да никто не будет таким заниматься...
Вот, вот, "комбинаторный взрыв", "значение могло устареть" и еще куча страшных слов в той статье и комментариях к ней. По-моему, задача слишком сложная, что бы ее решать вот так автоматически.