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

Эм... Я от них абстрагирован.

Мне плевать что в className написано.

+ вёрстка отдаётся на сторону.

Ну, у нас дизайнер шарит в css-in-js.

Вот, в этом разница.

Если всё нормально, то без проблем. К нашему проекту css-in-js не применимо.

Но он всё равно делает в css.

Мы слизываем стили с зеплина.

Вообще нормально.

Мы слизываем стили с зеплина.

Я не знаю что это.

А в SC разве можно? В styled-jss точно нет. Смотрю доку SC, и пока не нашёл.

Какая теперь разница когда есть новый context api)

Какая теперь разница когда есть новый context api)

А можно по-подробнее?

Я не знаю что это.

zeplin.io

Ну, у нас дизайнер шарит в css-in-js.

а дизайнер причем ? он же сказал что верстают гна стороне

zeplin.io

вообще топ тема

очень херово когда верстку дают на аутсорс

Ну, как есть.

проще своего научить а еще лучше что б дизайнер это умел делать

это прям вообще супер

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

проще своего научить а еще лучше что б дизайнер это умел делать

верстать дизайнеры ? ты че

верстать дизайнеры ? ты че

пусть хоть понимают как их дизайн будет в браузере жить

я уже не говорю о ux

пусть хоть понимают как их дизайн будет в браузере жить

их это не должно волновать. А верстка и ux причем ?

Ага, не должно, конечно.

А потом получаем паралакс, которой невозможно нормально реализовать.

А потом получаем паралакс, которой невозможно нормально реализовать.

+++

Или ещё какую-нибудь хреновину.

Ага, не должно, конечно.

я что то о UX сказал ? их не волнуют тонкости. А если рисуют заоблачный функционал то такое конечно нафиг не нужно

или мол у тебя тут шрифты не так рендерятся

я что то о UX сказал ? их не волнуют тонкости. А если рисуют заоблачный функционал то такое конечно нафиг не нужно

Это не ux, а всякие перделки, которые нереализуемы в браузере.

я что то о UX сказал ? их не волнуют тонкости. А если рисуют заоблачный функционал то такое конечно нафиг не нужно

должно быть понимание что можно сделать а что нет

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

проще своего научить а еще лучше что б дизайнер это умел делать

Научить нейронную сеть верстать по картинке и всё https://pikabu.ru/story/neyronnaya_set_kotoraya_verstaet_saytyi_po_kartinke_5629901

Идеально эт когда десигнеры сразу фигачат компоненты и из них собирают странички

А верстают они при этом или нет при таком подходе дело десятое

Я бы в withTheme хок вытащил и было бы норм.

Самый большой геморрой эт стопицот разных свистоперделок

Мне не нравятся рендер функции.

Самый большой геморрой эт стопицот разных свистоперделок

Если их кто-то реализовал, то без проблем)

Я бы в withTheme хок вытащил и было бы норм.

Тут нечего вытаскивать в хок, совсем

Тут нечего вытаскивать в хок, совсем

Меньше кода, проще читается.

Тут нечего вытаскивать в хок, совсем

Если их кто-то реализовал, то без проблем)

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

Но ладно, это вкусовщина.

Я не говорю меньше больше, я говорю что тут нет хока

Компонент Main получает свои пропсы и так же забирает через рендер проп ещё и определенный контекст

Я понимаю, но вот эту обвязку с прокидыванием темы я бы из компонента убрал и оставил бы просто содержимое рендер-функции.

А пропсы сверху откуда возьмутся?))

withTheme

Ты не понял, пропсы сверху это и есть сами пропсы компонента

Здесь уже обёрнуто всё

Я понял.

В качестве withTheme — Theme

Понимаю. И я считаю, что это не надо писать в компоненте.

Помимо всего прочего этот компонент атомарен и без темы лишён смысла и хорошего вывода типов

Эээ, походу ты не понимаешь меня.

Ну покажи как бы ты вынес, что осталось бы в Main)

Ну покажи как бы ты вынес, что осталось бы в Main)

Написал бы хок withTheme, который так же оборачивает переданный компонент A компонентом Theme и передаёт в A пропсом theme.

И потом бы просто его обернул в импорте.

Это, конечно, вкусовщина, но зачем в компоненте писать лишнее?

А, теперь вижу, действительно, два компонента никогда не лишние)

Эм?

Был один компонент с одним пропсом, стало двое с двумя

ты скажи ему что ник слишком длинный. ну рилли

Эм... А какие 2 компонента стали?

ERROR: S client not available

Эм... А какие 2 компонента стали?

Main + твой хок

Main + твой хок

Ну да.

ты скажи ему что ник слишком длинный. ну рилли

Могу вернуть старый local variables referenced from the lambda expression must be final

Не вижу в этом проблемы. Если код от чего-то становится чище, то надо делать.

+

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

Помимо всего прочего у тебя в типе пропсов компонента появляется сам контекст целиком

Вот так.

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

Вообще, scss адекватнее в плане размера кода, возможности вынести все в отдельные файлы\файл, дабы параллельно загружать и парсить отдельно от js-ки с куда большей скоростью

))0)

Не

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

Дык без проблем. Я посмотрел, что там есть тема и всё, больше туда не смотрю.

подскажите есть массив cчетов и в нем внутри показания по приборам, пользователь может их обновлять. как мне правильно организовать state

В данном случае, theme — это и есть контекст?

И меня хоки не волнуют.

Вообще, scss адекватнее в плане размера кода, возможности вынести все в отдельные файлы\файл, дабы параллельно загружать и парсить отдельно от js-ки с куда большей скоростью

не надо вбросов

В данном случае, theme — это и есть контекст?

Ага

А количество кода и размер сущности - это совершенно разные вещи.

Принимается непосредственно из источника контекстных данных

не надо вбросов

ну так правда же, еще и раздельное кеширование в придачу, что позволяет обновлять у клиента стили независимо от js-ки

@ZeroBias А если ещё что-то из контекста понадобится принять, то что делать будешь?

Так же? 2 рендер функции и 2 декоратора-объект?

В случае хоков у тебя проблемы никакой. Хоть 10 переменных из контекста. Компонент будет таким же лаконичным.

А кто сказал что контекст будет всего один?)

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

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

Почему по твоему типизации нет?

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

И возвращает назад проблему конфликтов имён контекстов

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

Хорошо. Давай я исследую этот вопрос и чуть позже продолжим беседу?) А то спать пора) у меня уже 4am

Хорошо. Давай я исследую этот вопрос и чуть позже продолжим беседу?) А то спать пора) у меня уже 4am

Ого, у меня только полночь