Еще несколько вопросов:
6) Будем ли мы удалять или стремиться удалить реквизиты xxxxStyle и попросим пользователей передать xxxClassName для замены стилей? Или они будут бесплатными?
7) Разрешим ли мы переопределение стилей через CSS и упростим интерфейсы наших компонентов. Итак, если я хочу переопределить menuItemStyle в IconMenu, могу ли я создать переопределение типа style = StyleSheet.create({ IconMenu: {MenuItem: { color:red }}) ?

@chrismcv Мое личное мнение состоит в том, что нам определенно нужно использовать решение для удаления этих суперсекретных реквизитов, которые мы видим, предлагаемые: [TextField] добавить опору FloatingLabelFocusStyle # 4043

Прежде чем мы это узнаем, люди будут просить реквизиты для стилей подкомпонентов для каждого возможного состояния focus / active / hover / любого состояния.

Я вижу так много проблем, как «как стилизовать XXXX», «нельзя стилизовать XXX внутри YYYY», «добавить somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle prop в XXX, пожалуйста»

@chrismcv в 6. Что вы думаете относительно более общих xxxxStyle props и classNames? с некоторыми из наших компонентов, которые вам так или иначе понадобятся (к счастью, мы сможем использовать :hover т. д.!).

@chrismcv Я думаю, что xxxxStyle props должно быть в свойстве style , а не в объекте стиля className .

@nathanmarks Спасибо за начало разговора. Это определенно одна из основных проблем, которые нам нужно решить в следующих выпусках 💯.

Вне проблем с производительностью

Для меня это одна из основных проблем, которые меня беспокоят в отношении решения, которое мы выберем.
У нас не так много тестов, но мы можем легко представить, что мы потеряли много циклов ЦП с нашим текущим подходом. Циклы ЦП теряются на выделение памяти и сборку мусора для нашего встроенного объекта стиля.

@oliviertassinari

В данный момент я играю с парочкой решений в стиле JS. Это интересно, но ясно, что это еще, так сказать, «первые дни».

Я подумал об одном - помимо свойств динамического стиля (например, если компонент имеет свойство color ), должны ли мы изменить способ создания объекта базового стиля?

Кажется, что с библиотеками в стиле JS, чтобы получить максимальную производительность, вы должны использовать их метод StyleSheet.create() один раз и иметь ключи (css "классы") в этом объекте для свойств / состояний, таких как open={true} вместо того, чтобы динамически создавать литерал объекта стиля с парой условных свойств и передавать его методу фабрики стилей при каждой визуализации для каждого стиля.

Несмотря на то, что селекторы таблиц стилей кэшируются в том смысле, что они записываются в DOM только один раз (а в некоторых библиотеках записываются в DOM только тогда, когда это необходимо для render() ), мы по-прежнему тратим ресурсы на некоторые вычисления. + создание объекта + сборка мусора, как вы упомянули выше, если мы создаем новый объект стиля при каждом рендеринге только для того, чтобы его выбросить.

Хммм ... Я оставил здесь комментарий вчера (воскресенье). Его удалили?

@rvbyron Я это хорошо помню. Я, конечно, не удалял его.

@rvbyron Я тоже это помню. Понятия не имею, что случилось.

@rvbyron - это было в моем электронном письме, поэтому вернемся сюда в цитируемой форме!

Что ж, я лично хотел бы, чтобы произошло несколько вещей.

A) Да, во что бы то ни стало отказаться от использования параметра стиля элемента на уровне библиотеки. Все компоненты должны быть определены с помощью className. Наличие стиля в компонентах разрушает все возможности CSS.
Б) Было бы замечательно, если бы classNames автоматически прикреплялись к корневому элементу каждого компонента (например, компонент RaisedButton неявно имел бы className = "mui -iled-button" в корневом элементе компонента). Это сделало бы укладку намного проще. Это даже можно настроить.
В) Полностью удалите тему из файлов muiTheme.js. Файл muiTheme.SCSS с темами был бы намного лучше, поскольку он позволял бы применять любые свойства, выбранные создателем темы, а не только те, которые специально разрешены компонентом. Конечно, это, вероятно, потребует, чтобы B. был реализован и активен.
D) React-look кажется хорошим компромиссом, поскольку он преобразует объекты JSON, содержащие свойства стиля, в classNames. Это упрощает переопределение. Однако, как я сказал выше в разделе C, я все же хотел бы, чтобы база тематики была создана в SCSS. Я не знаю, какой пакет помощи CSS использовать. Но я бы держался подальше от всего, что хотело бы использовать параметр стиля элемента вместо параметра className.

@chrismcv Спасибо, чувак!

Я думаю, что то, что должен сказать @rvbyron , важно, потому что в некотором смысле стиль JS во многом представляет собой сдвиг парадигмы от обычного CSS. Большинство людей не используют стили JS в своей повседневной работе, и это требует другого образа мышления + затрудняет работу дизайнеров, которые обычно вносят свой вклад в проекты, которые не так хорошо владеют JS.

Здесь важно учитывать все углы.

@oliviertassinari @chrismcv

В отношении react-look я понял одну вещь: вам нужно обернуть все свои компоненты в look HoC . Это кажется довольно инвазивным, он даже захватывает функцию render() , сохраняет super.render() в const и таким образом выполняет операции разрешения стилей. Для некоторых других решений, таких как Khan / aphrodite, просто требуется обертка функции вокруг ссылки styles.xxxx из Stylesheet.create() внутри className={} .

Взлом функции render() только для css кажется мне чрезмерно сложной. Он говорит мне, что встроенных инструментов / поддержки React для такого рода глубоко интегрированных функций стилей просто нет, я не уверен в идее CSS-помощника HoC, контролирующего рендеринг для всех наших компонентов.

Мысли?

Привет, команда Material-UI!

Я слежу за вами некоторое время, и теперь, просмотрев эту тему, я также хотел поделиться некоторыми мыслями о том, почему переход от встроенных стилей к css может быть хорошей идеей. Я прочитал много обсуждений в этом репозитории, которые касаются производительности рендеринга, стилизации дочерних / вложенных элементов, медиа-запросов, псевдоэлементов и т. Д., Поэтому я сосредоточусь на кое-чем другом, о чем я еще не встречался, и о котором еще не встречался, но я думаю, это тоже актуально. И это организация стилей. Вот что я имею в виду:

• Некоторые стили взяты из значений компонентов по умолчанию (которые установлены в папке узла и недоступны для прикосновения)
• Некоторые исходят из параметров компонента (например, параметр компонента аватара size={40} устанавливает ширину, высоту и высоту строки равными 40px )
• Когда параметры компонента по умолчанию настроены (цвета темы), стили поступают из места настройки темы
• Когда остальные стили компонентов изменяются, стили поступают из реализации компонента, которая является другой частью кода.

Когда дело доходит до настройки стилей, есть как минимум 4 разных места (👆), на которые нужно смотреть, что затрудняет исследование проблем.

Когда стили поставляются с css, вы увидите селектор и точно знаете, где исправить. При использовании встроенных стилей требуется время, чтобы понять, откуда взялось конкретное свойство, где и что следует изменить. И если разработчик изменяет его не в том месте (скажем, в области styles вместо параметра size , поскольку на самом деле ничего не говорит о том, что size - это стиль), это повлияет на производительность всего width=height=line-height=40px блока, или приведет к повторной записи width/height/line-height что сделает параметр size неприменимым.

Кроме того, это также затрудняет исследование того, к каким из родительских элементов применены определенные свойства, потому что все, что вы можете увидеть в инспекторе, это element.style .

Когда стили поставляются с селекторами (именами классов), это дает гораздо больший контроль над структурой стилей, чем встроенные стили.

Обновление: забыл упомянуть предложение (о котором идет речь в этой теме):

/component
--component.js
--component.css (or sass that is converted to css when the page is rendering)

Эта структура сохранит компонент в области видимости, но даст больше контроля над стилем. А соглашение BEM className поможет избежать ненужной вложенности:

.mui-component {}
.mui-component__child {}

Что в целом поможет реализовать, настроить и поддерживать стили Material-UI.

@chrismcv

Спасибо, что нашли письмо и поместили его в комментарий!

Лучшее из обоих подходов к поведению?

А как насчет "поведенческой" концепции импорта техники укладки, которая лучше всего соответствует вашим потребностям. Для выбора поведения можно использовать импорт «StyleTheme» или «ClassTheme». StyleTheme может относиться к объекту muiTheme material-ui, который есть сегодня, и порадовать разработчиков стилей, ориентированных на компоненты. Или ClassTheme, который будет использовать SCSS-файл, созданный из объекта muiTheme.js (синхронизированный), что сделает разработчиков, ориентированных на CSS, счастливыми. Это будет означать, что тогда все компоненты должны будут содержать {... theme.ComponentName} в элементах рендеринга.

Чтобы предложить очень упрощенный пример, компонент RoundButton будет иметь такой метод рендеринга:

render() {
    return (<button {...theme.RoundButton} />);
}

Для поведения StyleTheme theme.RoundButton будет содержать:

{ 
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

Для поведения ClassTheme theme.RoundButton будет содержать:

{ 
    className: 'mui-round-button'
}

Комбинация этих двух элементов может быть получена как поведение ClassStyleTheme, theme.RoundButton будет содержать оба:

{ 
    className: 'mui-round-button',
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

Файл mui-theme.scss будет сгенерирован из файла muiTheme.js и отразит в SCSS точные свойства, содержащиеся в файле JS. Верблюжий регистр имен JS будет преобразован в более стандартные имена классов:

mui-round-button {
    display: inline-block;
    border-radius: 20px;
    width: 40px;
    height: 40px;
}

Любая настройка CSS для компонентов MUI будет просто идентичными классами, загруженными после загрузки файла mui-theme.scss, тем самым переопределив свойства mui-theme.

@oliviertassinari

Я думаю, что использование чего-то вроде scss (+ css-модули для размещения имен / хеширования) имеет много преимуществ. Вы на 100% против этого? Я, вероятно, немного предвзято, потому что это то, что я привык использовать на работе, но многие люди находятся в одной лодке.

Моя основная проблема со стилем JS заключается в том, что кажется, что все решения все еще находятся в стадии разработки. Существует не так много реальных оценок производительности, на которые можно было бы взглянуть, библиотеки, которые мы рассматриваем, не проверены, и я чувствую, что мы тратим много времени, пытаясь выяснить, как правильно создавать стили в JS. Основная цель этой библиотеки - реализовать спецификацию материального дизайна, и я не могу не чувствовать, что в данный момент это нам мешает. (нам обязательно нужно отсортировать проблемы с производительностью)

Думаю, у нас по этому поводу разные опасения.

1. Где разместить статические стили (легко, файл css может сделать)
2. Как переключать некоторые стили в зависимости от ввода (переключатель className)
3. Как применять динамические стили (встроенные стили могут это сделать)

Когда вы пишете приложение, все кажется хорошим, никому вне вашего кода не нужно ничего менять.

Но с библиотеками все по-другому, есть все вышеперечисленные проблемы, плюс следующее:

1. Как разрешить пользователям настраивать статические стили?
2. Как реализовать тему таким образом, чтобы ее можно было легко переключать, настраивать и изолировать (разные поддерева, разные темы)?
3. Как избежать загрязнения глобального пространства имен, чтобы мы могли хорошо играть с другими?
4. Как пользователи могут переопределить встроенные динамические стили?
5. трансформаторы! (RTL, префикс и т. д.)

То, что у нас есть прямо сейчас, как-то решает все эти проблемы с помощью следующих оговорок:

1. Спектакль!
2. Глубоко вложенные компоненты сложно настроить, как сказал @nathanmarks : somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
3. Мы не можем использовать мощь некоторых функций CSS.

Если мы изменим наш подход к стилю, нам придется делать это снова и снова. Если дело дойдет до этого, мы обязательно ответим на все эти вопросы до начала миграции.

По моему скромному мнению, я думаю, что CSS и все, что в него компилируется, не являются частью будущего. Я думаю, мы все согласны с тем, что встроенные стили сделали нашу жизнь намного проще. Честно говоря, единственное ограничение, которое я вижу для inline-стилей, - это :hover !

Мы можем решить эти проблемы, сделав небольшой дизайн.

1. запомните объект стилей, для компонентов, которые имеют состояние, мы можем разбить состояние и поместить его в меньший компонент, чтобы объект стиля в нем можно было запоминать на основе переданных свойств, которые являются состоянием более высокого компонента. Это легко решаемо!
2. сломайте их! почему у нас есть ListItem с МНОЖЕСТВОМ встроенных мелких функций? мы можем разбить его на части и сделать его компонуемым, тогда нам не нужно добавлять чудовищ вроде somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
3. Мех! все, что мы получаем с производительностью, - это :hover Я думаю, мы можем жить с этим, пока браузеры или не отреагируют на это что-нибудь.

Я хочу сказать, что мы уже решаем огромное количество проблем с помощью нашего текущего подхода к стилизации. У него есть ограничения, потому что мы не следуем всем шаблонам встроенных стилей. если мы начнем разбивать наши компоненты и делать их намного более компонуемыми, тогда нам особо не о чем беспокоиться. take MeuItem Я взял это и сделал компонуемым, вы видите, как легко его использовать и как можно улучшить производительность с помощью чистого рендеринга!

Поэтому вместо того, чтобы менять наш подход и снова решать все эти проблемы, давайте потратим время на улучшение того, что у нас уже есть. нам не нужно поддерживать медиа-запросы, мы можем изменять наши компоненты таким образом, чтобы другие могли легко реализовать на них отзывчивость. Трудно отлаживать? если мы разбиваем наши компоненты, то встроенные стили будут меньше и легче читаются. спорный хотя! Я имею в виду, что все, что вам нужно, это точка останова, чтобы увидеть, что участвует в Object.assign чтобы увидеть, откуда берутся стили.

Это, конечно, мое собственное мнение. Я очень открыт для обсуждения.

@alitaheri

Вы поднимаете несколько замечательных моментов. Благодарю. Мне интересно, возможно ли какое-то гибридное решение. Кажется, что независимо от того, какой угол мы принимаем, возникает множество проблем 😆

У меня есть время поработать на следующей неделе - давайте поболтаем и посмотрим, сможем ли мы придумать какую-нибудь умную идею.

Я согласен с попыткой свести к минимуму количество изменений и с необходимостью повторно решать уже решенные проблемы. У меня в голове две важные цели:

1. Спектакль
2. Опыт разработчика (здесь очень помогают библиотеки в стиле JS, позволяя разработчикам с легкостью использовать классы в своих приложениях)

Надо подумать об этом больше 😄 но пока нам удастся решить эти 2 пункта, я буду доволен нашим решением.

Еще одно случайное замечание - было бы здорово, если бы у нас был автоматизированный способ обеспечения соблюдения определенных соглашений о коде и шаблонов проектирования для встроенного / jsstyle / любого другого в библиотеке.

Вы на 100% против этого?

@nathanmarks Я не на 100% против использования SCSS (_Я использую его на работе_). Но, с моей точки зрения, это тупик .
Одним из основных преимуществ React является абстрагирование от специфики рендеринга браузеров: DOM.
Насколько мне известно, долгосрочная цель React Core Team - предоставить API для написания кроссплатформенного компонента. Собственно, сейчас в этом направлении

Полностью согласен с @alitaheri. Мы могли бы начать с этих двух шагов:

• Используйте везде шаблон getStyles чтобы нам было легче выполнить миграцию позже.
  Сможем ли мы использовать codemod? Кто знает.
• Разбивка каждого компонента по предложению @alitaheri.

@oliviertassinari Согласен с тупиковым выводом - это не будущее. Я поднял его в основном для того, чтобы стимулировать разговор о том, как заставить стили JS работать на нас. Я знал, что у некоторых людей здесь есть несколько хороших идей по поводу проблем 😄 Желаю, чтобы FB немного продвинулся вперед вместе с их экспериментами!

Я действительно думаю, что у используемого сейчас шаблона getStyles() есть свои проблемы. Мы с @alitaheri сегодня неплохо поговорили о том, что нужно сделать, чтобы улучшить настройку нашего стиля JS (включая тематику!). Я отвечу завтра с дополнительной информацией, как только у меня будет возможность сделать заметки!

На следующей неделе я в отпуске и собираюсь поэкспериментировать с решением наших текущих проблем, сохраняя при этом все стили на основе JS.

Просто прочтите этот пост на Уроки, полученные в React Amsterdam (https://medium.com/@kitze/lessons-learned-at-react-amsterdam-51f2006c4a59#.o12h794or), и одна из презентаций была о решениях для стилизации в React: http : //slides.com/kof/javascript-style-sheets#/ Своевременная презентация для этого обсуждения.

Одно требование, о котором я все время думаю и о котором я не видел явно заявленного (по крайней мере, насколько я помню), - это необходимость поддерживать только веб-версию по сравнению с сетью и реагировать на нативную. Если намерение предназначено только для Интернета (т. Е. Нативное реагирование не является обязательным), то решения, которые используют то, что браузеры уже эффективно и надежно поддерживают и хорошо знакомы людям, были бы хорошей вещью. Если поддержка react native является обязательной, тогда это открывает другой набор потребностей и требований. Просто о чем следует подумать и иметь в виду при оценке выбора технологий, компромиссов и т. Д.

@hburrows

Спасибо, что поделились этой презентацией!

@alitaheri

Мы можем захотеть взглянуть на библиотеку, упомянутую в этой презентации ( вот демо ). Это могло бы сэкономить нам много работы. Я смотрел на это раньше, но было несколько вещей, которые мне не понравились (например, требование обернуть каждый отдельный компонент в проприетарный HoC). Тем не менее, некоторые из того, что здесь происходит, обсуждают. Он упоминает, что внедрение подобных изменений позволит использовать HoC-free. Я предпочитаю этот метод / дизайн для записи на листе (также видно в aphrodite ).

В качестве альтернативы, мы всегда можем создать собственные привязки реакции для jss которые могут работать с mixout .

Автор библиотеки также сказал это, что согласуется с моими собственными мыслями по этому поводу 👍:

Однако вы должны понимать, что не все имеет смысл быть таблицами стилей. Для наиболее динамичных изменений следует использовать встроенные стили.

@nathanmarks Реализация довольно маленькая и ее очень легко смешать: grin:
https://github.com/jsstyles/react-jss/blob/master/src/index.js
Думаю, эта библиотека может нам помочь: +1:

@alitaheri Да, я согласен!

Я также экспериментирую с некоторыми пользовательскими привязками для jss - есть несколько проблем / ограничений, которые я хочу попробовать решить. (Хотя может потребоваться работа над основной библиотекой)

Похоже, в сообществе React преобладает мнение, что стиль JavaScript - лучшее решение. Это мнение нормально, я не не согласен с теми, у кого оно есть. Однако способ реализации стилей JavaScript почти всегда не зависит от разработчика CSS. Реализация слишком часто отдает предпочтение style=/[element property]= над className= и мешает разработчику CSS выполнять свою работу.

Как я уже сказал в предыдущем комментарии, я думаю, что эти двое могли бы прекрасно жить вместе. Нужно просто применить поведенческий подход к применению свойств стиля. Библиотека должна поддерживать прямое применение свойств стиля к элементу или должна допускать косвенный подход создания className, состоящего из этих свойств стиля. Библиотека, которая позволяет разработчику выбирать поведение, кажется идеальным решением.

Есть много причин, по которым разработчики CSS не хотят просто отказываться от своего подхода. Выполните поиск по запросу «зачем использовать css», чтобы узнать, почему люди считают его полезным. Среди его преимуществ вы найдете абстракцию стилей и мощный селекторный язык. Давайте не будем забывать об огромном количестве кода, который существует сегодня, который приносит пользу пользователям CSS.

Опять же, это никоим образом не претендует на роль профессионального комментария CSS. Есть те из нас, кто хотел бы использовать CSS для стилизации. Этот комментарий предназначен для поощрения архитектурно нейтрального подхода к стилю, который дает разработчикам возможность выбора.

@rvbyron Одна из основных причин, по которой мы хотим изменить наш текущий подход, - это упростить настройку компонентов с помощью css. использование библиотеки типа jss позволит нам использовать функции css, используя преимущества js-стилей. И поскольку он превращает эти стили в css, их можно легко заменить дополнительным именем класса без уродливого хака !important .

@alitaheri Приятно слышать! Я действительно с нетерпением жду, когда material-ui приспособит подход, основанный на className.

Опять же, фантастика слышать о подходе className. Имея это в виду, у меня есть несколько вопросов о том, как это можно реализовать:

• Как вы думаете, как может выглядеть соглашение об именах имен классов?
• Все ли имена классов будут иметь префикс «mui-» или другой?
• Будет ли класс представлять собой обозначение тире имени компонента?
• Будет ли имя класса применяться к корневому элементу каждого компонента?

@rvbyron

Идеально:

Настраиваемый префикс. Нотация тире своего рода для лучшего опыта разработчиков и хешированный суффикс, который также может быть установлен в фиксированную строку (поэтому не изменится при изменении настроек темы) с использованием пользовательского идентификатора темы. Включая менее подробный производственный параметр или даже функцию обратного вызова для настройки. И я предполагаю, что класс в корне обычно всегда будет необходим в любом случае.

Я думаю, что перечислено много требований и предложено много предложений. Итак, есть ли вывод из всего этого обсуждения? Что делать дальше? Ведется ли работа по внедрению response-jss в этот материал-ui?

@rvbyron Ага, мы за кулисами экспериментируем с парочкой грубых идей. Обновим этот выпуск, когда у нас появятся более конкретные идеи.

По моему скромному мнению, я думаю, что CSS и все, что в него компилируется, не являются частью будущего. Я думаю, мы все согласны с тем, что встроенные стили сделали нашу жизнь намного проще. Честно говоря, единственное ограничение, которое я вижу для inline-стилей, это: hover!

Проблема в том, что: hover - это очень основная, очень важная часть стилей. Помимо футуризма, было бы разумно избегать преждевременного принятия решения, которое должно прибегать к читам и обходным путям для повторной реализации встроенной функции.

@wtgtybhertgeghgtwtg Мы работаем над решением, которое использует настоящие таблицы стилей, поэтому поддерживаются такие функции, как :hover .

Учитывая, что основные моменты были решены (стиль JSS с помощью className и корневых элементов classNames), есть ли какие-либо планы и сроки для выпуска material-ui v0.16.0?

@rvbyron У нас нет обещанных сроков, но на данный момент подход к стилизации и производительность являются нашим основным приоритетом в выпуске v0.16.0 и над чем мы сейчас активно работаем. Скорее всего, мы будем использовать эту проблему в ближайшем будущем для обратной связи с сообществом, как только выберем правильное направление в нескольких других областях, касающихся внутреннего устройства, API, миграции и т. Д.

@newoga Спасибо, Нил! Я ценю обновление. Что касается других проблем, я хотел бы добавить, что простой переход на систему, основанную на className, может быть визуально критическим изменением для многих, и я бы предложил ограничить этот выпуск только этим. Другие изменения в дополнение к этому могут действительно помешать миграции. Однако я знаю, что ваша команда выберет лучший баланс.

@newoga здесь jss был назван будущим системы стилей для material-ui. Достаточно ли это конкретный план, чтобы другие могли начать внедрять jss в наши проекты сейчас, в ожидании выпуска версии 16.0?

@sorahn еще нет

@sorahn Этот выпуск предназначен для того, чтобы получить отзывы сообщества о том, что по-прежнему сложно решить. Никаких официальных решений принято не было. На данный момент каждый должен выбирать и использовать только ту библиотеку стилей или подход, который, по их мнению, лучше всего подходит для них и их проекта.

Для записи, цель этого изменения стиля заключается не в том, чтобы перевести всех на какой-то другой стандарт, а в том, чтобы упростить использование и стилизацию компонентов пользовательского интерфейса материала независимо от того, какой подход к стилизации вы используете с ним.

tl; dr Нет! Делайте то, что лучше для вас, а не то, что говорят другие :)

@nathanmarks @newoga Спасибо за обновление!

Мы сталкиваемся с ограничениями адаптивного дизайна + рендеринга на стороне сервера со всеми встроенными стилями, поэтому мы исследуем альтернативы. Нет особенно сильных мнений по поводу css-modules, csx или чего-то еще, но мы любим material-ui, поэтому было бы здорово просто следовать тому, что вы, ребята, собираетесь делать :)

Я столкнулся с медиа-запросами, читал эту ветку (и другие). Я погрузился в некоторые возможные решения и статьи.

Мне очень нравится решение JSS + CSX (с точки зрения разработчика).

Преимущества и производительность JSS

Подобно @sorahn , я был бы счастлив принять стандарт material-ui, я надеюсь, что работа

@rosskevin Работая над этим, пока мы говорим, здесь есть вещи, которые не были охвачены ни одним из решений на сегодняшний день.

Наши требования намного шире, чем могут удовлетворить существующие решения, из-за проектных ограничений или мнений. Во многом это связано с тем, что существующие решения были разработаны с учетом приложений, в которых вы полностью контролируете использование API-интерфейсов компонентов, а не библиотеки, в которой у вас есть разнообразный набор пользователей, желающих стилизовать свои компоненты с помощью различных инструментов.

@sorahn Быстрый вопрос - что вы делаете с префиксами поставщиков при рендеринге на стороне сервера? Вы просто рендерете все префиксы на сервере? Или вы проходите UA?

@nathanmarks Мы отправляем пользовательский агент в браузер, но мне лично не нравится на это полагаться. Как насчет того, чтобы просто поместить их все по умолчанию и позволить людям переопределять их с помощью реквизита объекта muiTheme или наоборот, не делать ничего по умолчанию и разрешать людям выбирать.

muiTheme: {
  // other stuff...
  stylePrefixes: ['webkit', 'moz', 'ms']
}

@sorahn. Вы сможете делать все, что захотите: префикс, а не префикс, передавать all , передавать UA и т. д.

@nathanmarks Я только что выпустил [email protected]. Самое важное изменение - генерация детерминированного идентификатора, вот пример ssr с реакцией http://jsstyles.github.io/examples/index.html

Просто добавляю сюда свои 0,02 доллара ... хотя мне очень нравится идея встроенных стилей и мне нравится афродита, мне почти кажется, что было бы проще, если бы стили были основаны в формате библиотеки в scss, таком как bootstrap 4.

Обычно я буквально копирую файлы bootstrap.scss и _variables.scss при создании файла _mixins.scss ... с этой копией в ./lib/style, я обновляю локальный файл bootstrap.scss для ссылки на локальный переменных и миксинов, используя путь к версиям node_modules всего остального ...

Затем я настраиваю свою конфигурацию webpack, чтобы сделать ./lib/style частью пути поиска для конфигурации sassLoader.

Таким образом, у меня может быть файл main.scss, который загружает начальную загрузку и т. Д. Я могу оттуда ссылаться на переменные и / или миксины в остальной части моего проекта, и когда я создаю / связываю вывод, соответствующие стили будут включены.

Обратной стороной этого является то, что он предписывает использование material-ui в качестве источника (не предварительной сборки) и webpack для включения scss в пакеты. Тем не менее, это, вероятно, был бы наиболее простой путь использования существующих переменных, классов и миксинов стилей.

Опять же, мне очень нравится идея стиля JS, и, черт возьми, нравится то, что может предложить Афродита ... Я работал над чем-то похожим (собирался назвать это дерма) в качестве библиотеки стилей для встроенных стилей, но Афродита уже делает все, что я запланировано и многое другое.

Готово ли решение для укладки?

Есть ли обновления по этому поводу?

Да, ветвь next использует jss

Я только что наткнулся на этот проект и был очень взволнован, потому что он выглядел великолепно, страница с примером позволила очень легко понять, как использовать компоненты, и казалось, что он широко используется; однако я очень разочарован встроенными стилями и рад видеть, что вы, ребята, уходите от них. Одна из вещей, на которую я хотел бы обратить внимание, заключается в том, что все, что связано с макетом за пределами этих компонентов, должно быть удалено, и пусть стили родительского компонента справятся с этим. Компонент самого низкого уровня не должен иметь полей или отступов на нем, которые могли бы оттолкнуть окружающие элементы ... тем более, что это почти невозможно переопределить, не вмешиваясь в встроенные стили, что означает, что мне нужно покопаться и узнать, как это сделать. тот. Я особо не углублялся в этот проект, потому что, к сожалению, считаю его непригодным для использования. Я, конечно, читал много обсуждений встроенного стиля в сравнении с CSS. В любом случае, вы потеряли меня в TextField. Сверху есть поле 14 пикселей, а снизу - 16 пикселей. Я бы не возражал против слишком большого количества написания простого стиля, чтобы переопределить это, но это невозможно из-за встроенного стиля, и для меня было бы совершенно безумием создавать компонент более высокого уровня, чтобы полностью изменить это, как если бы вы обернули ваш компонент с помощью div и сделайте margin: -14px 0 -16px или немного скорректируйте его с расчетом так, как я хочу, но исправлять это каким-либо образом не обязательно. Я бы предпочел гораздо больше, если бы вы разрешили передавать className в качестве опоры, как вы это уже сделали, чтобы стили макета можно было применить к компоненту так, как ваше сообщество хочет его стилизовать. В любом случае, это мои 0,02 доллара.

Чтобы добавить к этому, создание компонентов типа макета для них или создание дополнительных свойств для обработки свойств макета может быть идеальным, например, использование системы сеток, такой как основа и начальная загрузка. Например, используя такие реквизиты, как размер, промежуток, ширина, столбцы и т. Д., Но начинайте без стилизации внешней части того, что видно с помощью компонента.

Я полностью с @ jbsmith969

Для меня было бы совершенно безумно создавать компонент более высокого уровня, чтобы полностью изменить это, например, обернуть ваш компонент с помощью div и выполнить margin: -14px 0-16px или немного настроить его с расчетом так, как я хочу

@ jbsmith969 Я согласен с тем, что компоненты низкого уровня не должны иметь никакой логики компоновки. Однако создание более абстрактного компонента для специфики вашего приложения вовсе не звучит безумно.
ИМХО, это один из самых мощных шаблонов, которые позволяет React (благодаря свойствам изоляции).

@oliviertassinari @ jbsmith969 Именно это мы и сделали! Мы создали наш компонент CustomTextField которому я передаю как 2 параметра (имя поля и цвет), и он просто выполняет небольшую логику вокруг них, а затем отображает material-ui/TextField с тем, что мы хотеть.

Это компоненты полностью вниз!

Итак, с помощью response мы берем наш html и помещаем его в наш js, и это нормально и здорово. Но взять наш css и засунуть его в наш html? Разве это никому не нравится?

В чем преимущество отказа от дерзости?

Назовите меня старомодным, но что плохого в разделении наших js / html и css?

Я законно ищу здесь ответы ...

В отношении https://github.com/callemall/material-ui/issues/3614#issuecomment -249095805 стили просто становятся компонентами.

Я вижу классы CSS как новые компоненты: (например, btn-danger -like из boostrap)

const DangerButton = ({ hoverColor, style, ...others }) => {
    return (
        <MUI.FlatButton
            hoverColor={hoverColor || Colors.pink100}
            style={{ color: Colors.black, ...style }}
            {...others}
        />
    );
};

Но переходы - это боль ..

(для @ jbsmith969 MUI следует спецификации Material Design. Если бы я не хотел следовать спецификации, я бы ожидал найти обходной путь. Однако я согласен с тем, что MUI трудно взломать, но это в основном из-за непоследовательного странного компонентные свойства, а не потому, что их стили встроены)

@vizath верно, у меня точно такая же мысль. Но каковы преимущества этого решения?

Если бы существовало решение, которое на самом деле работало бы не хуже, чем просто CSS, я бы решил попробовать. Однако, поскольку в настоящее время нет решения (о котором я знаю), которое могло бы сделать это без оговорок, я действительно не вижу апеала.

Почему это репо пытается адаптировать то, что кажется идеей альфа-стадии для решения, в очень полезную кодовую базу? Я просто не думаю, что мы находимся там с tec, и не думаю, что это подходящий испытательный стенд для этого tec.

@nathanmarks, можете ли вы посоветовать, как переопределить стили компонента с помощью JSS? Я использую последний код в next

РЕДАКТИРОВАТЬ: Хорошо, только понял, что он еще не полностью реализован. Виноват! 😬

Я пока не нашел хорошего способа избавиться от мертвого кода в ключах объектов, а с JSS он делает обязательным использование объектов для хранения стилей.

Случайный пример в компоненте ветки next (который не закончен): https://github.com/callemall/material-ui/blob/b372f6223ec2528dbe02f100e4802334f88445b7/src/IconButton/IconButton.js#L36
Я не могу найти способ надежно определить, что классы primary и accent не используются.

Мне не нравился способ управления встроенными стилями раньше в MUI по той же причине (lint перехватил бы неподписанные переменные, если бы стили были определены отдельно, см. Https://github.com/callemall/material-ui/blob/ 60a202fdc9645aa00f20c52e5152f168a1b0031b / src / IconButton / IconButton.js # L26).

В чем преимущество отказа от дерзости?

@gdaunton Это зависит от того, на какой стороне вы не используете подход inline-style / sass.

С точки зрения пользователя , это обеспечит следующие улучшения:

• Более быстрый метод рендеринга, так как мы будем полагаться на кешированные сгенерированные таблицы CSS.
• Упрощенное переопределение стиля, поскольку приоритет CSS ниже, чем у встроенного стиля, и пользователи могут использовать DevTools для определения листа, который нужно изменить.
• Быстрая первая отрисовка при рендеринге на стороне сервера.
  
  
  
  • Пользователи смогут встроить важные CSS-листы и только тот, который используется на странице. Это то, чего вы НЕ МОЖЕТЕ сделать с _Bootstrap_, поскольку это большой монолит 🙈.
  
  
  • Пользователи должны иметь возможность скрывать ключи имен классов в производственной среде.
  
  
• Нет встроенной цепочки зависимости, такой как _scss-loader_ или _Webpack_.

С точки зрения участника / сопровождающего , он обеспечит следующие улучшения:

• Больше никакого CSS-линтера
• Нет больше препроцессора CSS
• Нет синтаксиса CSS для изучения
• Гораздо более мощный язык для стилизации компонента: JavaScript.
• Откройте возможность абстрагироваться от движка стиля. Например, с помощью реакции со стилями

Почему это репо пытается перенять то, что кажется идеей альфа-стадии

Зависит от того, что вы подразумеваете под идеей альфа-стадии.
Мы далеко не единственные, кто использовал такой подход. Например, AirBnB, Khan Academy, ReactNative.

работал не хуже, чем CSS

CSS с самого начала разрабатывался для стилизации документов , а не компонентов .
Это серьезный сдвиг в нашей отрасли.

С моей точки зрения, компоненты для стайлинга - отстой .
Разработчики веб-спецификации хорошо осведомлены об этой проблеме и пытаются решить ее, используя стиль _Web Components_ с локальной областью действия.
Вы заметили все эти новые проекты с момента запуска React по улучшению CSS и написанию компонентного стиля?

Да, следующая ветка использует jss

@nathanmarks, где я могу узнать об этом изменении?

Нашел: https://github.com/callemall/material-ui/blob/next/docs/customization/themes.md

@bramick кажется, что это не о next потому что это работает, начиная с 0.15.0

Хорошо, мне не хватает того, что нового ... Кто-нибудь?

@bramick next еще не полностью документирован (однако у него есть сайт документации). На данный момент вам нужно прочитать исходный код, и вы можете ссылаться на исходный код сайта документации, чтобы увидеть, как он работает. Просто поймите, что некоторые из них все еще могут быть движущейся целью.

@oliviertassinari Вау! Спасибо за подробный ответ.

Не могу сказать, что полностью согласен, но вы демонстративно ответили на несколько моих вопросов.

Я согласен, мы должны (и движемся) двигаться к миру, в котором наши стили основаны на компонентах, а css для этого не годится. Однако (на мой взгляд) есть еще несколько морщин, которые нужно сгладить, прежде чем мы должны принять это в масштабе.

Мне любопытно, кто-нибудь смотрел, есть ли разница в производительности между этим и стандартным css? Я чувствую, что css все еще может иметь преимущество перед javascript; после загрузки ему все еще нужно сгенерировать и внедрить свои стили.

@gdaunton прочитайте о производительности jss на https://github.com/cssinjs/jss/blob/master/docs/performance.md

Это стандартный CSS в том виде, в котором он отображается, добавленный на страницу, но созданный внутри компонента. Я использую ветку next и она работает достаточно хорошо.

@newoga можешь прислать мне ссылку на то, о чем ты говоришь?

@bramick OMG! Это действительно просто, не правда ли? Например, для Button в next смотрите здесь .

Я понимаю привлекательность помещения CSS в файл JavaScript после успеха JSX, но не уверен, что делать то же самое со всем CSS приложения - хорошая идея. Я знаю, что у JSS есть несколько хороших вариантов использования, например, при работе со сверхсложными динамическими стилями.

Меня больше всего беспокоит то, что информация о стиле в конечном итоге загромождает определение компонента . CSS, выраженный с помощью объектов JavaScript, намного более подробный и сложный для организации . Например, в компоненте Button упомянутом в предыдущем посте, почти половина кода - это информация о стиле. Больше нет разделения проблем . Я знаю, что вы можете переместить код стиля в отдельный файл, но тогда нет никакого смысла помещать его в JavaScript на первом месте.

Для разработчиков самым большим недостатком является то, что они теряют всю интеллектуальную информацию для свойств CSS и их значений. На самом деле, мне нравится вся эта красивая структура кода и выразительность, которые препроцессор CSS может дать вам при правильном использовании.

Я не против того, чтобы мои проекты усложнялись, если это принесет больше пользы. Поэтому я никогда не возражал против лишнего линтера CSS, препроцессора, загрузчика и дополнительного синтаксиса, который мне пришлось выучить. Я также стараюсь оставаться открытым в отношении JSS, просто после первого взгляда он меня не убедил.

Меня больше всего беспокоит то, что информация о стиле в конечном итоге загромождает определение компонента.

Это полностью зависит от вас, зависит от того, как вы организуете свой код, если вы будете придерживаться некоторых правил, ничего плохого не произойдет (если говорить из производственного опыта 2 года).

CSS, выраженный с помощью объектов JavaScript, намного более подробный и сложный для организации.

На самом деле он менее подробный, потому что у вас более высокий уровень повторного использования кода и меньше повторений.

Для разработчиков самым большим недостатком является то, что они теряют всю интеллектуальную информацию для свойств CSS и их значений.

Я думаю, что цель здесь - дать пользователям material-ui возможность использовать все, что они хотят для стилизации. Автозаполнение для CSS - это аргумент, который я часто слышу. В основном это исходит от людей, которые мало использовали cssinjs, и это просто страх потерять некоторые удобства, к которым они привыкли.

Я не против того, чтобы мои проекты усложнялись, если это принесет больше пользы.

Я думаю, что все дело в том, чтобы уменьшить сложность и сделать кодовую базу более последовательной, простой в использовании и понимании, но все сложные сценарии охватываются одновременно.

Меня больше всего беспокоит то, что информация о стиле в конечном итоге загромождает определение компонента.

В нашем проекте мы извлекли информацию о стилях компонентов в отдельные файлы и загрузили их с помощью webpack. Основное преимущество заключается в том, что все хорошо организовано и что webpack может связывать код для каждого компонента, поэтому возможно разделение кода на js-код и информацию о стиле.

Также разделение проблем дается, когда вы разделяете логику для создания правил стилизации. Одним из примеров является то, что мы ввели функции фабрики стилей, которые производят стилевые функции, очень похожие на миксины в хорошо известных препроцессорах CSS.
Я хочу сказать, что вы получаете гораздо больше гибкости, чтобы моделировать свои собственные рабочие процессы и лучше всего адаптироваться к потребностям проекта и команды.

проверьте это https://styled-components.com/

Уже довольно поздно менять технологии, но я согласен, что styled-components очень многообещающе. Обрабатывает SSR, медиа-запросы, красивый синтаксис и так далее. По сравнению с JSS он также поддерживает автоматическую приставку и создание тем.

Насколько я знаю, он использует postcss внутри, что не дает приемлемой производительности при использовании во время выполнения, потому что это полный синтаксический анализатор css с множеством обработчиков крайних случаев и плагинов. Я мог бы представить себе предварительную обработку этого в JSS JSON, но, честно говоря, я не вижу особой пользы в использовании языка CSS и смешивании его с переменными JS и вызовами функций по сравнению с простым использованием JS полностью.

Стоит отметить, что текущая сборка styled-components уже уменьшена до 250

Это прекрасно для быстрого и простого прототипирования (презентационного) компонента, но я не вижу никаких преимуществ / функций, которые другие решения не могут предоставить.

Я согласен, я пробовал это в разрабатываемой мной библиотеке, и это было слишком тяжело для публикации. Я уверен, что они добьются прогресса в этом, но похоже, что работа над JSS здесь почти завершена и предлагает большинство тех же преимуществ.

Я использовал реагировать-набор инструментов в последнее время, они используют модули CSS для тематизации , которые в основном только полагается на WebPack - х sassLoader . Для меня это сработало очень хорошо. Может, стоит исследовать.

Привет, я должен согласиться с мнением поддержка тематики в react-toolbox просто потрясающая - я переключаюсь, поскольку настройка внешнего вида компонентов является наиболее важным аспектом истории внешнего интерфейса.

Я не думаю, что кто-то должен ожидать, что старый добрый стиль CSS когда-либо станет первоклассным гражданином в пользовательском интерфейсе материала, поэтому был запущен react-toolbox

По крайней мере, таково мое впечатление после прочтения множества выпусков и сообщений по этой теме. Я смутно помню такие вещи, как то, что команда стремится улучшить совместимость с React Native, и множество комментариев по поводу стилизации краевых случаев, которые намного проще решить с помощью JSS.

Однако эта информация теряется в ходе многих дискуссий. Поскольку это такая противоречивая тема, я думаю, что было бы невероятно ценно, если бы можно было иметь страницу Wiki о целях и философии проекта (написанную основными сопровождающими) с четким замечанием о том, почему стили Javascript так укоренились в фреймворк.

Мне очень нравится Material UI, потому что это самый активный и отточенный фреймворк для стилизации материалов для React. Однако использование JSS на всем протяжении вызывает у меня много головной боли, когда я хочу сохранить единый стиль со сторонними компонентами.

Что касается меня, я ценю то, как Material-UI делает стили в отличие от чего-то вроде react-toolbox, и вот почему: в одном из наших проектов у нас есть возможность для пользователя выбирать динамические темы:

Поскольку пользователь может выбрать цветовую пару, которую мы не можем определить заранее, какая бы схема тематики мы ни использовали, она должна быть очень динамичной. С участием, изменения в теме могут происходить в реальном времени, b / c все стили генерируются встроенными: все, что мне нужно сделать, это указать основные / акцентные цвета.

В react-toolbox et. др., насколько я могу судить, это кажется более сложной задачей.

@jrop да, в этом особом случае вам нужен динамический JSS, но для многих приложений это не является важным требованием, и текущая история настройки (даже не говоря о тестировании пользовательского интерфейса) material-ui просто неприемлема. Мы создаем очень наглядное и спроектированное приложение, которое не может просто использовать внешний вид материала по умолчанию, поскольку нам в основном нужны / нужны его части поведения.

@DominikGuzei вы можете настроить next с помощью jss. Это _не_ то, что вы видите в текущем выпуске.

Ребята, я чувствую, что мы здесь дохлую лошадь бьем. Ветка next выбрала другой (значительно улучшенный) путь с темами и допускает переопределения. Он больше не использует встроенные стили и обеспечивает требуемую гибкость. Для других, которым нужна большая настраиваемость, они могут использовать HOC над компонентами next и написать свои собственные таблицы стилей.

@nathanmarks , поскольку это решение было принято (насколько я могу судить, и работает довольно хорошо 👍), я предлагаю вам написать резюме и закрыть / заблокировать эту проблему, чтобы те, кто ее нашли, поняли, как двигаться вперед.

если бы можно было иметь страницу Wiki о целях и философии проекта (написанную основными сопровождающими) с четким замечанием о том, почему стили Javascript так укоренились в структуре.

@fgarcia Ранее на этой неделе я эволюции подхода к стилизации, используемого Material-UI. Возможно, вам будет интересно взглянуть на слайды и _notes_: Путешествие к лучшему стилю . Я сосредотачиваюсь на вызовах, проблемах и решениях.

пользователь выбирает динамические темы

Аспект создания статического стиля CSS-модулей имеет ряд последствий.
Внедрение стиля во время выполнения менее рентабельно, но позволяет нам:

• Дает нам больше гибкости при реализации стиля. Например, CircularProgress имеет фиксированный thickness связанный с тем, как реализована анимация ключевых кадров CSS. С динамическим стилем мы можем добавить свойство толщины, чтобы пользователи могли динамически изменять значение. ⚠️ не злоупотреблять.
• В крупномасштабном приложении он позволяет вводить только необходимые стили для отображаемого компонента на экране. Уменьшение объема работы, необходимой браузеру для загрузки страницы. Следовательно, более быстрое время для первого рисования после взаимодействия. Например, встраивание критического CSS с помощью SSR.
• Разрешить пользователям использовать динамическую тему и вариации компонентов. Например, изменение цвета кнопки со всеми необходимыми цветовыми вариациями.

@oliviertassinari Приятно слышать. У меня может быть нестандартная точка зрения на модули CSS, но я не думаю, что они того стоят. По этой причине я был взволнован, услышав о JSS через material-ui. Кажется, это гораздо больше соответствует философии JavaScript, чем модули CSS.

@oliviertassinari благодарит за краткое изложение преимуществ. Это определенно интересно, когда вы смотрите на эти аспекты. Обратной стороной JSS и его экосистемы (также postcss) на данный момент является то, что все это является передовым, и вы не можете полагаться на хорошо отлаженную цепочку инструментов и базу знаний, как с простыми css-модулями + SASS. Но это цена, которую вы платите за инновации, это просто зависит от того, есть ли у вас определенные требования / вы готовы платить цену за ошибки и менее документированный путь.

JSS был создан до css-модулей. CSS-модули стали популярными быстрее, потому что они решили проблему для большинства пользователей, не меняя слишком радикально синтаксис.

При этом вы используете реакцию, которая также является «новой» технологией. Если вам нужен SASS, возможно, вам стоит также выбрать vanilajs или backbonejs)

@kof React - это совсем другая история, поскольку он используется сотнями тысяч разработчиков и управляется Facebook (он не исчезнет в одночасье), поэтому он может быть «новым», но очень надежным (не сталкивался с много проблем с этим пока).

SASS - один из наиболее распространенных препроцессоров css, который можно использовать в любом проекте - он очень надежен и приносит большую пользу. Поэтому я бы выбрал что-то вроде JSS только в случае крайней необходимости (например, из-за динамических тем), но не люблю тратить годы опыта / фреймворков / базы знаний и т. Д. В коммерческий программный проект с несколькими разработчиками. Так что я бы даже подумал о создании только динамического аспекта темы в JSS, а остальное с помощью sass / css-модулей.

Я понимаю такой образ мышления, но также считаю его контрпродуктивным и виню его в замедлении инноваций и замедления развития отрасли.

Почему ты просто не поддерживаешь обоих? Стили написаны на JavaScript и стили написаны в css-модулях? Если я взгляну, например, на https://github.com/callemall/material-ui/blob/next/src/Button/Button.js , было бы довольно просто использовать имена классов, переданные с помощью свойства ( https://github.com/javivelasco/react-css-themr) вместо использования:

const classes = this.context.styleManager.render(styleSheet);

Не так ли?

Не похоже, чтобы обсуждение использования JSS или CSS подошло к концу (пока?). На мой взгляд, сейчас это похоже на пятьдесят на пятьдесят.

Что касается SASS, react-toolbox в настоящее время

Очевидно, что стилизация во всем JS, и в React в частности, все еще находится в стадии быстрой эволюции. Поэтому что бы вы ни делали, я бы старался не быть самоуверенным - просто хорошо подходил для широкого круга текущих задач.

Попробуйте просто добавить опору * className везде, где есть опора стиля *. Период.

Полное раскрытие: я счастливый пользователь Афродиты.

Добавление className прежнему потребует !important хаков, потому что встроенные стили (из свойства style ) имеют приоритет.

@ligaz Конечно, ты прав. Афродита по умолчанию добавляет !important ко всему, так что, возможно, мои мысли о «широком спектре использования» сильно искажены.

@ligaz @estaub - next уже закодирован _without_ style и позволяет пользователям компонентов переопределить, предоставив className (и несколько имен классов для различных частей сложных компонентов) .

При настройке парадигмы стиля на ветке next сопровождающими используется JSS. Это приятно использовать, и его легко переопределить на индивидуальной или тематической основе.

Эта лошадь мертва. Давай перестанем его бить. @oliviertassinari Я предлагаю вам закрыть и заблокировать эту проблему с next .

Привет, @rosskevin, не могли бы вы указать мне на какие-нибудь примеры того, как это работает дальше?

В настоящее время я ищу фреймворки для нового проекта, я бы хотел использовать Material UI, но нам потребуются изменения, о которых вы упомянули, в следующем. Я добавил следующую ветку в тестовый проект и добавил простой компонент, и я вижу инспектор, полный встроенных стилей, так что я предполагаю, что делаю что-то не так?

Любые дополнительные подробности были бы очень полезны!

благодаря

@giuseppepaul next не публикуется на npm, потому что это предварительная альфа-версия и еще не завершена. Вы можете клонировать https://github.com/callemall/material-ui.git#next и запустить docs/site чтобы убедиться, что встроенных стилей больше нет. Он также имеет разумное количество демонстраций.

Я публикую свою собственную частную версию next (чтобы я мог контролировать обновления) и использую ее в готовом к выпуску приложении.

Эта лошадь мертва. Давай перестанем его бить. @oliviertassinari Я предлагаю вам закрыть и зафиксировать этот вопрос,

Эта лошадь не полностью мертва. Но точно в затруднительном положении 🔫.
Согласен, закроем этот вопрос.

Большое спасибо @nathanmarks за его тяжелую работу над этой историей 👏!
Я собрал больше информации о дороге впереди с № 5718.

Здравствуйте,
IconButton имеют свойство CSS3 transition для эффекта пульсации. В сложном взаимодействии документа Card @next вы добавили transition к преобразованию для добавления перехода, когда значок переворачивается.
Если я сделаю то же самое в своем приложении, один переход (рябь или реверсия) переопределит другой (элемент не может иметь два свойства, иначе одно переопределяет другое).
Однако к вашему значку шеврона успешно применены два transitions . Потому что каким-то образом вы объединяете переходы, предоставленные IconButton и переходы, определенные в вашем коде. Как этого добиться?
Некоторые другие вещи для меня непонятны, и я не могу найти соответствующий документ. theme имеет много методов / свойств, например breakpoints (здесь не используется) transitions (используется здесь). Есть ли уже документ о свойстве theme того, что возвращает MuiThemeProvider.createDefaultContext() поскольку он кажется полезным, особенно если он широко используется внутри вашего кода.
this.context.styleManager.render(styleSheet) ? Какая ?
Вы также используете jss-theme-reactor смысл которого я до сих пор не понимаю по сравнению с react-jss .

@NitroBAY Эта тема окончена. Задайте вопрос по правильному каналу. Если вы заметили ошибку или хотите улучшить документацию, откройте вопрос. В противном случае вы можете использовать StackOverflow из gitter.im.