Да, вы правы. Об этом и был мой пост, что вы должны выбрать, то что актуально для решения вашей задачи в вашей компании. Там же находится ваша собственная граница нормы гибкости.
— Как мейнтейнеры библиотек находят свободное время для их поддержки, не занятое продуктовыми задачами?
У нас много мейнтейнеров и мы стараемся переводить контрибьюторов в этот статус. Сейчас по факту их уже около 6, хотя мы ленивы и не обновляем список в package.json. Выглядит, так что такое количество справляется с текущим количеством контрибьюторов из команд. Каких-то жестких правил нет.
— При выпуске новой версии библиотеки каким образом она попадает в места использования старой версии?
Мы дистрибьютируемся через npm и старательно следим за semver.
— Как пользователи, желающие использовать компонент интерфейса, могут узнать, что он уже реализован?
Либо посмотреть на демо странице alfa-laboratory.github.io/arui-feather/styleguide
Либо, если компонент родился на продукте, но не был занесен в библиотеку — может просто увидеть на готовом продукте, найти команду, которая его реализовала и забрать в библиотеку.
— При доработке готового компонента интерфейса как контролируется, что не будут сломаны места, где он используется?
Здесь можно поиграть словами про реализацию vs спецификацию. Но по-сути все-равно. Пока ваша дизайн-система живет в браузере и, каждый, браузер реализует спецификацию HTMLElement. Нас не должно это беспокоить.
Вы сами ответили на свой вопрос — WebComponents — это спецификация, а не реализация. И я говорю только про слой, за который отвечает дизайн-система — визуальное представление с минимальной логикой компонентов-виджетов.
Пока дизайн-система живет в браузерах нас не должно смущать, что мы залочены на его стандартизированные api. Но мы становимся полностью свободными в выборе решений для построения всего остального приложения: Angular 1, Angular 2, React, Vue, mobx, redux, flux — можно смешать со всем.
Styled-components выглядят вкусно. Будущее может быть разным…
Мне импонирует подход Styled-components лаконичностью внешнего API. Не импонирует тем, что это большой черный ящик и то, что это по-прежнему tech-lock на React.
Привет. Писал выше, что особо не выбирали дизайн api декоратора — просто стремились к более короткой записи. Вариант с контекстами имеет право на жизнь.
1.
Особо не задумывались над дизайном декоратора, когда делали. Хотелось просто получить в `render` максимально короткую запись. Но есть такие запросы от команд — им, кажется, так удобнее. Возможно в будущем добавим честный публичный интерфейс через `this.props`.
2.
Потребность в DI появилась чуть позже. Опять же хотелось сохранить максимально просту запись без получения конструктора компонентов из `this.props`. Просто добавили добавили проксирование через аргументы, не затрагивая методы `render` всех компонентов.
3.
Мы используем Postcss с набором плагинов. Проталкиваем просто через css import.
Это нам один раз помогло сильно, когда мы кардинально меняли дизайна на новый. Для многих компонентов было достаточно заменить переменные и получить новый компонент бесплатно.
Помогает по мелочи, когда мы подтягиваем соответствие переменных между WebView и нативным приложением.
Привет. Все ± верно. Мы не делаем embeded api, типа Яндекс Карты API, в которым мы бы решали задачи, как максимально защитить стили. И, иногда, позволяем себе «срезать углы» засчет переопределений.
Привет. Я специально не останавливался на выборе стека технологий, потому что рассказывал уже об этом — можно посмотреть видео доклада: www.youtube.com/watch?v=yfIsPH1jXJc
Если, кратко, то незаменимое преимущество BEM — это простота и то, что css — это просто css, он работает почти так как написан (мы все-таки помогаем себе немного при помощи postcss).
Вероятно эксперименты с другими подходами стилизации будем пробовать, но если упремся в какую-то действительно фатальную проблему подхода.
Посоветуйте что-нибудь для игрушек (xbox 360). Наверное, 42-47 дюйма. Бюджет, думаю, в районе $1600. Не интересно ни вай-фай, ни 3д, ни возможность читать файлы. В основном к панели будет подключаться консоль и ноутбук, чтобы показать с него кино. Спасибо.
Мне кажется это как когда Microsoft назвала приставку xbox 360, вместо xbox 2, чтобы ассоциироваться с головах на уровне с PS3, а не уходящей с рынка PS2.
У нас много мейнтейнеров и мы стараемся переводить контрибьюторов в этот статус. Сейчас по факту их уже около 6, хотя мы ленивы и не обновляем список в package.json. Выглядит, так что такое количество справляется с текущим количеством контрибьюторов из команд. Каких-то жестких правил нет.
Мы дистрибьютируемся через npm и старательно следим за semver.
Либо посмотреть на демо странице alfa-laboratory.github.io/arui-feather/styleguide
Либо, если компонент родился на продукте, но не был занесен в библиотеку — может просто увидеть на готовом продукте, найти команду, которая его реализовала и забрать в библиотеку.
1. Unit тесты
2. Регрессионные тесты скриншотами
3. Жесткое следование semver
4. Жесткое следование deprecation policy github.com/alfa-laboratory/arui-feather/blob/master/DEPRECATION_POLICY.md
И, да, иногда ломаем обратную совместимость.
Styled-components выглядят вкусно. Будущее может быть разным…
Мне импонирует подход Styled-components лаконичностью внешнего API. Не импонирует тем, что это большой черный ящик и то, что это по-прежнему tech-lock на React.
1.
Особо не задумывались над дизайном декоратора, когда делали. Хотелось просто получить в `render` максимально короткую запись. Но есть такие запросы от команд — им, кажется, так удобнее. Возможно в будущем добавим честный публичный интерфейс через `this.props`.
2.
Потребность в DI появилась чуть позже. Опять же хотелось сохранить максимально просту запись без получения конструктора компонентов из `this.props`. Просто добавили добавили проксирование через аргументы, не затрагивая методы `render` всех компонентов.
3.
Мы используем Postcss с набором плагинов. Проталкиваем просто через css import.
Например, вот так выглядят переменные цветов для темы:
github.com/alfa-laboratory/arui-feather/blob/master/src/vars/color-theme_alfa-on-color.css
Это нам один раз помогло сильно, когда мы кардинально меняли дизайна на новый. Для многих компонентов было достаточно заменить переменные и получить новый компонент бесплатно.
Помогает по мелочи, когда мы подтягиваем соответствие переменных между WebView и нативным приложением.
Если, кратко, то незаменимое преимущество BEM — это простота и то, что css — это просто css, он работает почти так как написан (мы все-таки помогаем себе немного при помощи postcss).
Вероятно эксперименты с другими подходами стилизации будем пробовать, но если упремся в какую-то действительно фатальную проблему подхода.