ахаха) я забыл об этой фиче

?

И все четко выходит

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

А какая разница

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

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

Окей, а зачем оно мне, если у меня нет нужды в цсс как таковом?

А какая разница

меньше кода при использовании

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

Ну наверное, так лучше чем style писать

А какая разница

<Element x={1} y={2} /> vs <Element style={{ top: 1px, left: 2px }} />

<Element x={1} y={2} /> vs <Element style={{ top: 1px, left: 2px }} />

Ну да так лаконичней

дело не в лаконичности

если надо будет поменять единицы, ты можешь это сделать

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

Типизировать первый вариант попроще будет всяко

Ну да так лаконичней

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

Ну ок ок, так действительно правильней

sc и типизация. Ахахаха

sc и типизация. Ахахаха

=(

sc и типизация. Ахахаха

Вообще, странно, что так нельзя, это же нативная реализация f<T>``

sc и типизация. Ахахаха

Чё не так

Ну, где тайпинги под flow?

Вообще, странно, что так нельзя, это же нативная реализация f<T>``

В тс принесли вроде пр

Месяц назад завести пытались. И нифига.

Вообще, если понять, что любая ф-я может быть вызвана через `` - можно придумывать такие ненормальные штуки :crazy:

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

хз, мне не удобно когда css и js в одном месте. Может пока кейсов особо не попадалось где это было бы нужно.

хз, мне не удобно когда css и js в одном месте. Может пока кейсов особо не попадалось где это было бы нужно.

https://github.com/artalar/blog/blob/master/src/pages/styled-components-part-1-the-new-architecture.md

Ну, где тайпинги под flow?

В глаза долбишься?

В глаза долбишься?

Ты выполнил что там написано? Или просто прочитал?

Ты выполнил что там написано? Или просто прочитал?

Ты спросил где тайпинги

Я тебе показал

Мде...

Если у тебя что-то не работает, мб не в SC проблема?

Это не тайпинги. Это способ установить того, чего нет.

Чё не так

а нафига простите для sc тайпинги? я что-то не понимаю или с какого они тут бока?

Хотя... За месяц ситуация изменилась. Виноват.

а нафига простите для sc тайпинги? я что-то не понимаю или с какого они тут бока?

Входные пропсы типизировать

Плюс внутренние функции тоже

а нафига простите для sc тайпинги? я что-то не понимаю или с какого они тут бока?

И чтобы вывод типов работал.

И чтобы вывод типов работал.

сову понял, тебя нет

И чтобы вывод типов работал.

Не могу вспомнить, он там нужен разве?

const Fork = styled(SomeAnotherComponent)`` и все :)

const Fork = styled(SomeAnotherComponent)`` и все :)

А

Т.е. все типы при этом потеряются, я правильно понял?

Т.е. все типы при этом потеряются, я правильно понял?

Надо проверить. Недавно тайпинги кто-то закинул в репу.

const Fork = styled(SomeAnotherComponent)`` и все :)

Кстати, это сильно костыльный способ?

Кстати, это сильно костыльный способ?

нормальный вполне

Кстати, это сильно костыльный способ?

@sergeysova Я, когда UI кит пишу, делаю, например, ButtonBase, а потом форкаю его и делаю еще какие-то кнопки. Ты, вроде, делаешь стили buttonBase через css апи SC, а потом их используешь в костамных кнопках. Как лучше?

extend лучше, но на входе нужен sc комопнент

extend лучше, но на входе нужен sc комопнент

extend деприкейтед

extend деприкейтед

зачем?))))

extend деприкейтед

И это хорошо

зачем?))))

Потому что это дубль styled(). extend выпилят в следующих версиях

Потому что это дубль styled(). extend выпилят в следующих версиях

Плюс неочевидный, работающий только с другими sc

@sergeysova Я, когда UI кит пишу, делаю, например, ButtonBase, а потом форкаю его и делаю еще какие-то кнопки. Ты, вроде, делаешь стили buttonBase через css апи SC, а потом их используешь в костамных кнопках. Как лучше?

Надо смотреть внутреннюю реализацию. Он складывает все в одну функцию или же бегает по двум.

Плюс неочевидный, работающий только с другими sc

Ну есть обсуждение в issue на гитхабе, найдите, почитайте

Надо смотреть внутреннюю реализацию. Он складывает все в одну функцию или же бегает по двум.

Ну то есть у форка будет два класса свой и парента Или один свой

Ну то есть у форка будет два класса свой и парента Или один свой

У форка точно два

У форка точно два

Ну если мы не считаем класс-ид?

Последнее что я читал, каждый форк (врапер) просто создает новый класс, так же как и extend

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

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

Зачем extend, если можно просто обернуть? Ну зачем?

Выглядит красиво - да. На практике излишне, еще и связанность повышает

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

Если делает одно и то же, зачем два способа

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

Это как если бы у массива был ещё один метод each

а после объединения, уже нужно будет им делать что то одно для всего)

а после объединения, уже нужно будет им делать что то одно для всего)

Не обязательно

Они могут внутри проверять

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

Хуже всего - это понимать - стилизуешь ты SC компонент или что-то другое :) Значит проблемы с модульностью

Хуже всего - это понимать - стилизуешь ты SC компонент или что-то другое :) Значит проблемы с модульностью

в идеальном мире)

Хуже всего - это понимать - стилизуешь ты SC компонент или что-то другое :) Значит проблемы с модульностью

Я вообще редко расширяю и стилизую компоненты

У меня обычно styled.div))

я в либе мучался хотел сделать иконки для расширения через extend, у меня атомы чистые sc, теперь нафиг тупо засуну реактовский компонент, раз останется только styled

Почему если state объявить не в конструкторе, он все равно будет работать как и ожидалось?

что-то другое приводит к обновлению и рендер подхватывает новый стейт

что-то другое приводит к обновлению и рендер подхватывает новый стейт

Соответственно так делать плохо?

ну если тебе init state не нужен

вообще, да. Любое обновление стейта после этапа инициализации компонента только через setState

вообще, да. Любое обновление стейта после этапа инициализации компонента только через setState

Так оно и делается через setstate, просто сам Стейт вне конструктора объявлен

Так оно и делается через setstate, просто сам Стейт вне конструктора объявлен

такая запись это установка стейта на этапе инициализации, это норма

такая запись это установка стейта на этапе инициализации, это норма

Это точно? Просто мне на собеседование сказали про это, якобы нужно именно через конструктор объявлять

Это точно? Просто мне на собеседование сказали про это, якобы нужно именно через конструктор объявлять

ну я бы посмеялся в ответ)

ты бы им myMethod = () => {} показал бы, их вообще порвало бы)

такая запись это установка стейта на этапе инициализации, это норма

А где можно что-нибудь почитать про это? Просто реально интересно, но в доках реакта через конструктор объявляют стейт

А где можно что-нибудь почитать про это? Просто реально интересно, но в доках реакта через конструктор объявляют стейт

https://babeljs.io/repl/#?babili=false&browsers=&build=&builtIns=false&code_lz=MYGwhgzhAEAyD2JoG8BQ1oGsCmnoF4UN0NoREAuaAcmwCNFqSBfVVoA&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&lineWrap=false&presets=stage-2&prettier=false&targets=&version=6.26.0&envVersion=

https://babeljs.io/repl/#?babili=false&browsers=&build=&builtIns=false&code_lz=MYGwhgzhAEAyD2JoG8BQ1oGsCmnoF4UN0NoREAuaAcmwCNFqSBfVVoA&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&lineWrap=false&presets=stage-2&prettier=false&targets=&version=6.26.0&envVersion=

А, дошло, спасибо

Это точно? Просто мне на собеседование сказали про это, якобы нужно именно через конструктор объявлять

сеньерское собеседование?

сеньерское собеседование?

Junior

ну хоть так

? Ребята, только не бейте. Как строку с html <p>LOVE</p> распарсить/отрендерить/сделать компонентом? Есть что-то вроде HTML.parse(...)

? Ребята, только не бейте. Как строку с html <p>LOVE</p> распарсить/отрендерить/сделать компонентом? Есть что-то вроде HTML.parse(...)

https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml