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

как раз таки языков для css куча, а js один и скорее всего разраб будет его знать

так все говорят у кого нет аргументов. назвался груздем полезай в кузов

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

Динамические стили — в js, остальное можно и в css оставить

А вот это более здравая мысль

правила от этого не поменяются

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

например?)))

мож я слепой)

например?)))

можно ленту просмотреть еще раз.

можно ленту просмотреть еще раз.

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

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

у тебя как раз аргумент один — JS JS ТОЛЬКО JS НЕ ХОЧУ ДРУГИЕ ЯЗЫКИ

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

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

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

напиши плиз на js стиль, который @keyframes использует

а, уже на личности скатились

чуть выше

не на личности, ты реально это по-кругу повторяешь

не хочу учить другое, есть js, js ftw

и игнорируешь все, что тебе говорят

а вы чем лучше? вот я не спорю, молодец, привел аргумент про @keyframes. почему бы было сразу с этого не начать?)

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

всего этого js не умеет

зачем нужны вложенный классы?)

как это не умеет) не, я не спорю, макросов в js нет, что очень жаль

ну в смысле .class { &-container { } }

а именно

. class { &:hover {} }

вот это вообще киллер фича

++

И &:before

http://take.ms/sMLFz

http://largescalejs.ru/

как раз таки языков для css куча, а js один и скорее всего разраб будет его знать

1) Есть такая вещь, как разделение труда. И согласно этой штуке, мир вертится не только вокруг js-дрочеров. Есть ещё такие профессии в IT, как верстальщик, который не обязан вникать в премудрости JS'а (хоть и желательно чтобы знал) 2) Есть такое понятие, как "передача проекта другой команде". Так вот, другая команда не обязана вникать в вещи, которые не закреплены ни одной спецификацией. 3) Огромные возможности пре/пост процессоров, которые, к примеру, позволяют наследовать стили и объявлять их только в одном месте, а не копипастить их из компонента в компонент. Ну и последнее, изучение других языков (программирования/разметки/стилей) помогает развивать фантазию и мозги, заставляя искать пути оптимизации и улучшения своего рабочего процесса. Что сказывается на личном росте как специалиста.

мы не про jss/styled componets сейчас

А потом ты grep´ом начинаешь искать класс в этих ваших киллер-фичах

а я как-то отошел от консоледрочерства, IDE прокликивает на ура в таком классы

http://largescalejs.ru/

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

Ну, а так-то, конечно, дело твоё. Но я бы отказался от саппорта твоего кода. Мне не очень хочется разбираться в компонентах на 10к строк

ребята

вспомните

когда-то люди ругались на препроцессоры

1) Есть такая вещь, как разделение труда. И согласно этой штуке, мир вертится не только вокруг js-дрочеров. Есть ещё такие профессии в IT, как верстальщик, который не обязан вникать в премудрости JS'а (хоть и желательно чтобы знал) 2) Есть такое понятие, как "передача проекта другой команде". Так вот, другая команда не обязана вникать в вещи, которые не закреплены ни одной спецификацией. 3) Огромные возможности пре/пост процессоров, которые, к примеру, позволяют наследовать стили и объявлять их только в одном месте, а не копипастить их из компонента в компонент. Ну и последнее, изучение других языков (программирования/разметки/стилей) помогает развивать фантазию и мозги, заставляя искать пути оптимизации и улучшения своего рабочего процесса. Что сказывается на личном росте как специалиста.

2 пункт какой-то стремный. С таким подходом лучше ни во что вообще не вникать, а уступить место нормальным людям

и тоже не нравилось

1) Есть такая вещь, как разделение труда. И согласно этой штуке, мир вертится не только вокруг js-дрочеров. Есть ещё такие профессии в IT, как верстальщик, который не обязан вникать в премудрости JS'а (хоть и желательно чтобы знал) 2) Есть такое понятие, как "передача проекта другой команде". Так вот, другая команда не обязана вникать в вещи, которые не закреплены ни одной спецификацией. 3) Огромные возможности пре/пост процессоров, которые, к примеру, позволяют наследовать стили и объявлять их только в одном месте, а не копипастить их из компонента в компонент. Ну и последнее, изучение других языков (программирования/разметки/стилей) помогает развивать фантазию и мозги, заставляя искать пути оптимизации и улучшения своего рабочего процесса. Что сказывается на личном росте как специалиста.

1) если в твоей компании нет вертальщиков, то этот пункт отметается. 2) я не говорю что нужно убрать декларативные правила css, я не понимаю зачем это делать в другом файле на другом языке. какая спецификация обязывает писать это в другом файле? 3) если стиль привязан к компоненту как ты его переиспользуешь. хотелось бы пример увидеть. ну и последнее, ты меня не знаешь и не знаешь какие языки я знаю. так что надо указывать мне

Ну, а так-то, конечно, дело твоё. Но я бы отказался от саппорта твоего кода. Мне не очень хочется разбираться в компонентах на 10к строк

wat? какие компоненты на 10к строк кода? о чем ты вообще

очень плохие))

логика же вся в контейнерах

вон в RN нет никаких css файлов отдельных и че то никто не умирает

когда-то люди ругались на препроцессоры

+

а стили лежат в стейтлесс компонентах

и все хорошо

вот тебе и разметочка и стили сразу

1) если в твоей компании нет вертальщиков, то этот пункт отметается. 2) я не говорю что нужно убрать декларативные правила css, я не понимаю зачем это делать в другом файле на другом языке. какая спецификация обязывает писать это в другом файле? 3) если стиль привязан к компоненту как ты его переиспользуешь. хотелось бы пример увидеть. ну и последнее, ты меня не знаешь и не знаешь какие языки я знаю. так что надо указывать мне

1) Мир вертится не только вокруг тебя и твоей компании 2) Чтобы не раздувать файл компонента кодом, которму там не место. Ты же не пишешь для каждой сущности отдельный класс, а используешь наследование от других? 3) Можно пример такой привязки? Тебе никто ни на что не указывал, не нужно воспринимать в свой адрес то, что в него не говорили.

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

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

по-мне вполне все удобно

Напоминает споры про jsx

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

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

ахаха

про jsx и правд

1) Мир вертится не только вокруг тебя и твоей компании 2) Чтобы не раздувать файл компонента кодом, которму там не место. Ты же не пишешь для каждой сущности отдельный класс, а используешь наследование от других? 3) Можно пример такой привязки? Тебе никто ни на что не указывал, не нужно воспринимать в свой адрес то, что в него не говорили.

что кто то мешает сделать отдельный js файл и там прописать стили)

что кто то мешает сделать отдельный js файл и там прописать стили)

Дык с тем же успехом ты можешь создать и css/scss/less/чотамещё файл

@personafour вот например привязка) стили специфичные для данной вьюхи

Как понять когда основные стили стали динамическими или наоборот? Когда они стали динамическими - тогда они стали динамическими, А когда они стали статическими - тогда они стали статическими Что делать, если стало необходимо стили одного компонента расшарить другому? Расшарить стили компонента другому компоненту Все просто же

А т.к. ты всё равно пишешь CSS в JS, то CSS ты и так знаешь

Как понять когда основные стили стали динамическими или наоборот? Когда они стали динамическими - тогда они стали динамическими, А когда они стали статическими - тогда они стали статическими Что делать, если стало необходимо стили одного компонента расшарить другому? Расшарить стили компонента другому компоненту Все просто же

Согласен. Подайте человеку лодку)

@personafour вот например привязка) стили специфичные для данной вьюхи

чем они специфичные?

ты их где то переиспользуешь?

https://gist.github.com/anonymous/4757aad66a8b08cc0ae43c1729835ee3

и?)

ERROR: S client not available

composes ом подтягиваются иконки для каждого компонента, иногда из одного компонента в другой перекидываю так-же composes om стили

ну так именно эти классы же нигде больше не используются

значит стили специфичные для данного компонента

ты спросил зачем выносить, тебе привели N аргументов, неужели еще остаются вопросы?

да, иногда можно не выносить, если эти аргументы не работают

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

будешь выносить в отдельный файл

не проще сделать сразу

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

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

Можно. Но лично я пока не вижу действительно весомого аргумента это делать. Возможно всё изменится. когда мы наконец получим готовую спеку по web-компонентам

победила дружба ура)

не увидел в обсуждении несколько действительно важных аргументов за css не в js, по крайней мере для меня)) - отдельный бандл (ну или чанки) только со стилями. здорово тем, что можно отдельно что-то пофиксить/изменить только в стилях, и пользователю будет достаточно загрузить лишь новые стили, но не приложение (наоборот аналогично). и сюда же важный момент про критичные стили - их также можно вынести в отдельный бандл, чтобы грузить сразу, а остальные по возможности. вместе с SSR это даст серьезный буст для первичного отображения контента, например. - оставляем браузеру возможность для статического анализа стилей и соответствующих оптимизаций - css и js - все же разные технологии, обрабатываемые браузером по-разному. и чтобы писать эффективный css, нужно его все-таки знать, как и особенности его рендера, поэтому аргумент про знание лишь js кажется странным - ну и раз уж мы выносим стили в отдельный файл (так ведь банально удобнее даже с jss, с точки зрения ответственности, читаемости и тд), то почему не написать этот файл собственно и на css? тем более, что препроцессоры действительно дают лучший синтаксис, проработанный в сообществе годами, удобство, тулинг и прочее

Всем привет! Хотел бы узнать кто, как использует данный кейс. При переходе на страницу с id продукта, если в стэйте нет товара, необходимо попробовать загрузить его с сервака.

Всем привет! Хотел бы узнать кто, как использует данный кейс. При переходе на страницу с id продукта, если в стэйте нет товара, необходимо попробовать загрузить его с сервака.

componentDidMount+componentWillRecieveProps

не увидел в обсуждении несколько действительно важных аргументов за css не в js, по крайней мере для меня)) - отдельный бандл (ну или чанки) только со стилями. здорово тем, что можно отдельно что-то пофиксить/изменить только в стилях, и пользователю будет достаточно загрузить лишь новые стили, но не приложение (наоборот аналогично). и сюда же важный момент про критичные стили - их также можно вынести в отдельный бандл, чтобы грузить сразу, а остальные по возможности. вместе с SSR это даст серьезный буст для первичного отображения контента, например. - оставляем браузеру возможность для статического анализа стилей и соответствующих оптимизаций - css и js - все же разные технологии, обрабатываемые браузером по-разному. и чтобы писать эффективный css, нужно его все-таки знать, как и особенности его рендера, поэтому аргумент про знание лишь js кажется странным - ну и раз уж мы выносим стили в отдельный файл (так ведь банально удобнее даже с jss, с точки зрения ответственности, читаемости и тд), то почему не написать этот файл собственно и на css? тем более, что препроцессоры действительно дают лучший синтаксис, проработанный в сообществе годами, удобство, тулинг и прочее

ты можешь для прода собирать отдельный css

ты можешь для прода собирать отдельный css

а может есть ссылка под рукой для styled components? простой гугл и пробег по доке не помог

не увидел в обсуждении несколько действительно важных аргументов за css не в js, по крайней мере для меня)) - отдельный бандл (ну или чанки) только со стилями. здорово тем, что можно отдельно что-то пофиксить/изменить только в стилях, и пользователю будет достаточно загрузить лишь новые стили, но не приложение (наоборот аналогично). и сюда же важный момент про критичные стили - их также можно вынести в отдельный бандл, чтобы грузить сразу, а остальные по возможности. вместе с SSR это даст серьезный буст для первичного отображения контента, например. - оставляем браузеру возможность для статического анализа стилей и соответствующих оптимизаций - css и js - все же разные технологии, обрабатываемые браузером по-разному. и чтобы писать эффективный css, нужно его все-таки знать, как и особенности его рендера, поэтому аргумент про знание лишь js кажется странным - ну и раз уж мы выносим стили в отдельный файл (так ведь банально удобнее даже с jss, с точки зрения ответственности, читаемости и тд), то почему не написать этот файл собственно и на css? тем более, что препроцессоры действительно дают лучший синтаксис, проработанный в сообществе годами, удобство, тулинг и прочее

и сюда же важный момент про критичные стили - их также можно вынести в отдельный бандл, чтобы грузить сразу, а остальные по возможности. вместе с SSR это даст серьезный буст для первичного отображения контента, например. css in js позволяет более гибко использовать критичные стили, без лишних зависимостей которые будут в вашем случае, без парсинга хтмл и файлов с цсс. - оставляем браузеру возможность для статического анализа стилей и соответствующих оптимизаций Браузер делает все тоже самое и при стилях вставленных через жс! - css и js - все же разные технологии.... Вода какая-то -тем более, что препроцессоры действительно дают лучший синтаксис, проработанный в сообществе годами, удобство, тулинг и прочее И время ребилда увеличивается с количеством ваших тулингов, чего нет при использовании другого подхода Получается аргументов важных нет

и сюда же важный момент про критичные стили - их также можно вынести в отдельный бандл, чтобы грузить сразу, а остальные по возможности. вместе с SSR это даст серьезный буст для первичного отображения контента, например. css in js позволяет более гибко использовать критичные стили, без лишних зависимостей которые будут в вашем случае, без парсинга хтмл и файлов с цсс. - оставляем браузеру возможность для статического анализа стилей и соответствующих оптимизаций Браузер делает все тоже самое и при стилях вставленных через жс! - css и js - все же разные технологии.... Вода какая-то -тем более, что препроцессоры действительно дают лучший синтаксис, проработанный в сообществе годами, удобство, тулинг и прочее И время ребилда увеличивается с количеством ваших тулингов, чего нет при использовании другого подхода Получается аргументов важных нет

как боженька сказал, особенно про критикал цсс

а вот интересно про какие такие оптимизации идет речь? ?

> Браузер делает все тоже самое и при стилях вставленных через жс! но ведь ему все то же самое надо будет делать при каждом ре-рендере компонента. поправьте, если не прав

не при каждом

в случае с жсс стайл теги вставляются при маунте и удаляются при анмаунте

это всё

в случае с жсс стайл теги вставляются при маунте и удаляются при анмаунте

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

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

зачем их туда выносить ?

я описал выше, зачем

бандл у тебя просто один жс

проблема котороую решает критикал цсс

это блоат стилей

там была не только проблема с критикал цсс

в случае с цссинжс у тебя нет блоата стилей

проблемы нет