что бы переопределять

что бы переопределять

Делаешь это прямо в приложении

по некоторым требованиям нужно уметь переопределять из листов стилей

короче по старинке шоб

во втором случае ты можешь контролировать названия классов, они предсказуемы?

профита от этого нет

в нашем случае это нужно уметь

переопределять

по некоторым требованиям нужно уметь переопределять из листов стилей

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

Либо можно скомбинировать инструменты, но это немного усложнит работу со стилями

я считаю работу с css-классами в реакте устаревшим способ управлять внешним видом компонентов

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

я считаю работу с css-классами в реакте устаревшим способ управлять внешним видом компонентов

а как нужно?

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

а нужно делать приложения, в которых на конструирования стилей в рантайме пофиг

иначе этот дзен не постичь

лол

а как нужно?

нужно чтобы эту работу делал инструмент styled-jss, styled-components, emotion

инкапсулировать стили надо просто как-то

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

Этот юзкейс идеально покрывается тем, что я рассказал Конкретнее Сова знает

чтобы потом когда на какой react-native переехал не пришлось переписывать всю логику к хуям

стайлд компонентс - это для апп, в которых вся асинхронность только от пользовательского взаимодействия

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

aka сайтики

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

Вообще не проблема, юзеры могут не составлять темы из классов (и ломать внещний вид сайта/приложения) А просто составлять объект из цветов, просто выбирая цвета в форме, например

если вместо <Button type=“success”> <a style={{color: ‘green’}}>

Вообще не проблема, юзеры могут не составлять темы из классов (и ломать внещний вид сайта/приложения) А просто составлять объект из цветов, просто выбирая цвета в форме, например

неплохое предложение

стайлд компонентс - это для апп, в которых вся асинхронность только от пользовательского взаимодействия

с чего ты взял?

но оно все же несколько будет не такое гибкое

Вообще не проблема, юзеры могут не составлять темы из классов (и ломать внещний вид сайта/приложения) А просто составлять объект из цветов, просто выбирая цвета в форме, например

Ты наверняка можешь найти ссылку на инструменты с примерами)

но оно все же несколько будет не такое гибкое

Куда гибче?) Все на уровне приложения!)

с того, что в реалтайме стайл компонентс ботлнек

можно конечно через препак теоретически пропускать

с того, что в реалтайме стайл компонентс ботлнек

не знаю, что нужно сделать, что именно SC стали узким местом

но тогда вообще динамика в рантайме пропадёт, и смысл по сути теряется, только синтаксис кому-то удобнее

нужно сделать rt аппу

и потом выпилить стайлд компоненты

все просто

но оно все же несколько будет не такое гибкое

http://www.material-ui.com/#/customization/themes вот здесь можно светлую/темную темы переключать

но тогда вообще динамика в рантайме пропадёт, и смысл по сути теряется, только синтаксис кому-то удобнее

суть SC как раз в динамических стилях без ручного тупого оперирования классами

и потом выпилить стайлд компоненты

и начать охуевать от жонглирования классами

суть SC как раз в динамических стилях без ручного тупого оперирования классами

так сколько раз тебе динамические стили нужны были?

и начать охуевать от жонглирования классами

можно оставить их и охуеть от того, что твоим говном никто не пользуется

и потом все равно переписать нормально

и начать охуевать от жонглирования классами

не надо ими жонглировать, компоненты ftw

потому что кушать надо

так сколько раз тебе динамические стили нужны были?

Забавно. Как только начинается новый проект, я предлагаю SC, если они подходят То люди сразу находят применение, дизайнеры прыгают от счастья, потому что множество фич можно легко и быстро реализовать на SC

можно оставить их и охуеть от того, что твоим говном никто не пользуется

блабла ибо без пруфов

пруфы у Макса

что это медленно

У всех больших сервисов динамических стилей много ,SC в каждый дом

автора стайлд компонент

с того, что в реалтайме стайл компонентс ботлнек

а если реалтайм с темами

причем в докладах его это тоже есть

блабла ибо без пруфов

Ты, так-то, тоже не утруждаешься.

в КАЖДОМ из

не надо ими жонглировать, компоненты ftw

И что, компоненты. Внутри компонента получается classNames(class, { foo: !!props.foo, bar: props.bar === 'bar' }) и ещё 50 строк такого говна

конструкции типа <Container /> вместо <div className="Container" /> и <Heading /> вместо <h1 className="Heading" /> это очень даже хорошо ничего не мешает в таком стиле писать без определения стилей в рантайме

рил ток

антихайп

синк эбаут ит

рил ток

че рил без SC динамические стили превращаются в боль особенно нормальная реализация тем условные стили, тем более

Кастомизированные компоненты с SC делать проще

че рил без SC динамические стили превращаются в боль особенно нормальная реализация тем условные стили, тем более

я говорю, что для сайтиков sc ок

И что, компоненты. Внутри компонента получается classNames(class, { foo: !!props.foo, bar: props.bar === 'bar' }) и ещё 50 строк такого говна

а со стайлд компонентс то же самое, только с пропсами что ли? это уже вопрос организации, 50 строк подобной хрени в определении класса сложно получить

я говорю, что для сайтиков sc ок

делал и рилтайм сервис, с апдейтами по 10-12 раз в секунду

Кастомизированные компоненты с SC делать проще

да это верно, только как часто от этого реальный профит? тем более что из css-modules можно перменные тоже в js использовать

да это верно, только как часто от этого реальный профит? тем более что из css-modules можно перменные тоже в js использовать

жонглирование классами никуда не девается весь контент render() метода, превращается в сплошные className={classNames(...............)}

да это верно, только как часто от этого реальный профит? тем более что из css-modules можно перменные тоже в js использовать

Часто 30 вариантов кнопок,это вообще норма

че рил без SC динамические стили превращаются в боль особенно нормальная реализация тем условные стили, тем более

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

Ну не 30

А 10

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

в SC не буду и в styled-jss тоже

в SC не буду и в styled-jss тоже

Покажи.

Лёль.

Покажи.

я вообще не знаю, что такое классы в SC я оперирую одним объектом на уровне провайдера <ThemeProvider theme={this.state.currentTheme}>

могу менять его как захочу

а в компонентах ровно ничего не меняется

> нормальная реализация тем у blueprintjs для dark / light переключатеся ОДИН класс в body скольким проектам надо хоть две темы? Динамическая темизация это реально редкое требование.

Часто 30 вариантов кнопок,это вообще норма

30 вариантов кнопок это не динамическая темизация

я вообще не знаю, что такое классы в SC я оперирую одним объектом на уровне провайдера <ThemeProvider theme={this.state.currentTheme}>

Там строка?

ну зависит

> нормальная реализация тем у blueprintjs для dark / light переключатеся ОДИН класс в body скольким проектам надо хоть две темы? Динамическая темизация это реально редкое требование.

почитай мое сообщение выше

Там строка?

ОБЪЕКТ

Ок

Но.

у кого-то переключалка с розового на радужный - это и есть аппа

им sc ок

30 вариантов кнопок это не динамическая темизация

Я про кастомизацию

у кого-то переключалка с розового на радужный - это и есть аппа

открой google plus когда переключаешь разделы сайта оформление меняется

почитай мое сообщение выше

ну я прочитал я не вижу ответа на вопрос как часто это нужно наверное также часто как командная строка в сайте, позволяющая пользователям js выполнять :)

открой google plus когда переключаешь разделы сайта оформление меняется

не знаю даже зачем мне это делать :)

у меня был проект, в котором при открытии профиля компании, должен был меняться акцентный цвет на цвет бренда

вот КАК это реализовать на обычном css?

ммм

да легко

как всю жизнь делали

ну и плюс.... css properties

ну я прочитал я не вижу ответа на вопрос как часто это нужно наверное также часто как командная строка в сайте, позволяющая пользователям js выполнять :)

как дизайнеры захотят, так сразу нужно будет

Изи катка так-то