Это обсуждалось несколько раз раньше, но я не думаю, что был какой-либо вывод, и PR, намеревающиеся решить проблему, не были объединены по разным причинам.
Я хотел бы закрыть эти PR как устаревшие и перезапустить обсуждение по этому поводу.
Учитывая производительность, вывод @syranide выглядит следующим образом:
Нам следует вообще не допускать противоречивых стилевых правил.
- https://github.com/facebook/react/pull/2013#issuecomment -57338177
ИМХО, учитывая все обстоятельства, лучше просто запретить перекрытие и предупредить в dev.
- https://github.com/facebook/react/pull/4661#issuecomment -132996649
Radium от @ianobermiller пришел к такому же выводу в https://github.com/FormidableLabs/radium/issues/95, но впоследствии произошла некоторая обратная реакция. React Native, похоже, допускает расширение стилей, но только для нескольких атрибутов (например, margin
и padding
, но не border
).
Я закрываю старые запросы на вытягивание по этому поводу и создаю эту проблему для отслеживания реализации поведения, с которым мы, кажется, согласны: мы должны предупреждать в __DEV__
когда border
и borderBottom
используются одновременно. В этом вопросе мы можем обсудить более конкретную специфику (следует ли игнорировать? Можно ли разрешить некоторые свойства из белого списка, но предупредить о других?).
В качестве стратегии миграции мы можем предложить людям использовать что-то вроде https://github.com/ActionIQ/style-builder, если им действительно нужны эти ярлыки. Это также то, что нам нужно решить при реализации интегрированного стиля.
Связанные вопросы:
Связанные PR:
@gaearon Спасибо, что
Мне нравится идея предупреждать о сокращенных свойствах, таких как border
, но не borderBottom
. Не должно быть сюрпризов при объединении стилевых объектов с использованием более длинных имен свойств.
Вопрос. Является ли цель этой проблемы только анализом отдельных стилевых объектов или есть также желание проанализировать и предупредить о возможных конфликтах свойств, которые применяются условно?
Вопрос. Является ли цель этой проблемы только анализом отдельных стилевых объектов или есть также желание проанализировать и предупредить о возможных конфликтах свойств, которые применяются условно?
Не уверен, что понимаю вопрос, не могли бы вы уточнить?
Конечно. Если недопустимо наличие в одном элементе и border
и borderColor
, то имеет смысл предупредить об этом. По моему опыту, этой комбинации легко избежать, но ее сложнее предвидеть и отлаживать, когда стили применяются динамически (условная логика на основе свойств или состояния, медиа-запросы, Radium и т. Д.) Или передаются как свойства и объединяются. с объектами стиля более низкого порядка. Если предупреждение для сокращенного атрибута border
возникает, когда нет других атрибутов, которые могут повлиять на задействованную границу, тогда предупреждение больше похоже на догматическое правило, чем на полезный инструмент отладки, поскольку сокращенное обозначение border
является все еще технически действующий. Однако, если есть атрибут в отдельном объекте стиля - например, изменение borderColor
при наведении - это повлияет на задействованную границу и будет применен во время выполнения к узлу, который уже имеет сокращенное обозначение border
, я хотел бы получить предупреждение как можно раньше, потому что именно здесь у меня что-то ломается.
Ах, хорошее замечание. Я бы, наверное, предупредил, только если мы _знаем_, что стили перекрываются, но я не уверен, насколько легко это определить. Я не особо задумывался над этим, и у меня нет хорошего решения.
@gaearon Альтернативное решение, которое мне больше нравится, - это использовать csstext согласно https://github.com/facebook/react/issues/5397 , который IIRC чисто решает надмножество этих проблем.
Как насчет ситуаций, когда сторонний компонент определяет стили и разрешает переопределения? Допустим, компонент определяет свой собственный стиль border
и я хочу просто переопределить стиль borderBottom
?
Я начал работать над очень простыми вспомогательными функциями для преобразования сокращенных свойств в длинные (среди прочего): https://github.com/rtsao/lostyle/tree/master/src ( docs )
Это очень непредсказуемо и запутанно, и я только что столкнулся с этим.
Я бы посоветовал по крайней мере предупреждать об обновлениях, когда мы знаем, что это проблематично? То есть, если мы переходим от {background: a, backgroundSize: b} к {background: c, backgroundSize: b}, предупреждаем, что backgroundSize переопределяется (но если backgroundSize изменяется одновременно, не предупреждать). Мы можем сделать это для всех сокращений свойств и узнать, проблематично ли это, из порядка перечисления свойств.
Отметка как «хороший первый выпуск». Давайте добавим для этого предупреждение только для разработчиков на мой комментарий выше. Я думаю, что хорошее место для начала расследования было бы здесь:
Если вы хотите заняться этим, прокомментируйте здесь, чтобы у нас не было двух человек, работающих над этим.
@sophiebits , я счастлив поработать над этим :)
@supertinou Это твое!
Просто ударил по нему, и это действительно удивило и смутило.
@supertinou Просто хотел проверить, могу ли я чем-нибудь вам помочь.
@sophiebits Привет, я не хочу никому наступать на пальцы: D, но я изучил эту проблему, воспроизвел ее и хотел бы поработать над ней, но я не знаю, работает ли @supertinou все еще Это.
Я сделал код, чтобы подвести итоги / объяснить, что происходит https://codepen.io/giuseppegurgone/pen/mjKbmq?editors=0010 @gaearon / @sophiebits, дайте мне знать, если я что-то забыл.
@mirkojotic Все еще интересно?
Если никого нет, я бы взял эту :)
Хорошо, @YongPilMoon , это твое.
Добавление примечания: удаление свойства также может вызвать эту ошибку. https://stackoverflow.com/q/52636618/49485
Предупреждение отсутствует в 16.13.
https://reactjs.org/blog/2020/03/02/react-v16.13.0.html
Самый полезный комментарий
Как насчет ситуаций, когда сторонний компонент определяет стили и разрешает переопределения? Допустим, компонент определяет свой собственный стиль
border
и я хочу просто переопределить стильborderBottom
?