Охотно верю. Но не наоборот же? Не художник же за студентами дорисовывает? Я тоже в раскраске могу что-то узнаваемое нарисовать (хоть и карандаши криво держу), но сам с нуля я не нарисую.
Если вы так хорошо знаете TS, то почему настойчиво закрываете глаза на приведенные примеры?
Я вам говорю, что у меня на вход 3 параметра (может больше, может меньше) и у меня валидация всех параметров как внутри SC, так и в вызывающих компонентах. Вы мне в ответ шлете реакт-компонент с отрисовкой div-а с передачей в него CSS-селекторов. Да, понятное дело, что можно заточить отдельный реакт-компонент, суть которого будет только в принятии указанных параметров и формирования конечного набора className, стили для которых уже сформированы и тут типа тогда проверка будет всего и все и очень похоже на то, что в моем примере. Но вопрос: а будет ли тогда это сильно быстрее работать, если суть логики все равно выполняется в реакт-компоненте (то есть в рантайме, против которого вы и топите?). Это очень похоже на одно и то же. И воторой момент, о котором я говорил выше: использование других styled-компонентов в качестве селекторов. SC это поддерживает нативно. А в вашей реализации я что должен делать? if(props.children instanceof OtherComponent) {...}? Так чтоли? Зачем мне все это переписывать, если SC имеет из коробки?
Вот и получается, что вы говорите «Вам это не нужно, потому что в целом это поддерживается там, почти все». А я в ответ говорю «Мне того почти всего не достаточно, мне надо все». И я точно знаю, что мне надо, а не выбираю из чего-то незнакомого. Я и то и другое уже изучал и выбор осознанно сделан, даже если вы этого не понимаете.
И говорю еще раз: можно завязывать с обсуждением, я не хочу жевать одно и то же без толку.
Type '{ isOpened: boolean; }' is not assignable to type 'DetailedHTMLProps<HTMLAttributes, HTMLDivElement>'.
Property 'isOpened' does not exist on type 'DetailedHTMLProps<HTMLAttributes, HTMLDivElement>'.ts(2322)
Это же TS, он никак не зависит от styled-components
От TS вообще почти ничто не зависит. Конечный JS все равно будет работать как JS, и можно забить на ошибки. Но TS вводят не для того, чтобы на него забивать, а чтобы он помогал, и чтобы было видно где что и как. И как раз в этом плане React+SC+TS — это как раз очень хороший союз. Если здесь TS исключать, то я бы вообще не стал спорить. Более того, так и сидел бы дальше на less.
Проблема в том что у вас это указано внутри компоненты и обеспечивается там же и теми же механизмами что и у меня. Т.е. в этом месте у нас нет никакой разницы в коде. У вас это отдельный компонент, и у меня. У вас это тип props-ов, и у меня. У вас там тип указан как boolean, и у меня. Всё одно и то же.
Нет, разница большая, в том, что у вас это два отдельных не связанных друг с другом компонента. Один генерит стили и кто хочет, тот пусть их и юзает, а не хочет — пусть не юзает. А кто хочет юзать, то пусть внимательно смотрят что именно передают. А в моем случае это два взаимосвязанных компонента, живущих совместной жизнью, и изменение одного влияет на другого.
Не понимаю. У вас какой-то оторванный от жизни пример. Я беру и пишу тег без класса. Зачем я его пишу?
Это из серии спора JS-разработчика и TS-разработчика. Вроде пишут практически на одном языке, а парадигмы совсем разные (по себе знаю, потому как не один год на чистом JS писал, прежде чем на TS перейти).
Отвечаю: нет, у меня очень даже не оторванный от жизни пример. Просто вы проблемы не видите, вот и решение вам не интересно. Так вот, в вашем случае проверка только на передачу класса, передан он или нет. При этом передаваемый класс (селектор) — это просто строка. Так вот, вы можете только проверить на то передан был класс или нет. При чем className="" — это как бы тоже передан, потому что параметр есть и он строковый, хоть это и пустая строка. А можно передать className=«dsf sdfhegr tr wefwef sdf dsf и еще много всего», и валидировать здесь нечего, есть значение и ладушки.
В моем же примере возможно использование нескольких отдельных переменных и конечный вызов может быть таким:
И я каждый параметр в отдельности могу валидировать и готовить под них нужные стили, а не просто проверять передан ли какой-то произвольный параметр или нет.
Отношение такое имеет, что здесь говорит «Вы не указали opened», то есть обязывает меня указать opened={true||false}, а не как у вас, что просто нельзя передать несуществующий параметр. Здесь как раз можно свои параметры добавлять, рулить их типы и обязательность.
Еще раз: вы оперируете только css-селекторами. SC позволяет работать с произвольными параметрами и дополнительно использовать логику для формирования стилей.
Да, мы друг друга не поймем, скорее всего. Я тогда не знаю что вы вообще под типизацией подразумеваете. Если только наличие/отсутствие переменных, то это не так. Типизация подразумевает именно типы, то есть, к примеру, если у меня указано opened: boolean, то и передать можно только opened={true||false}. Если я потом меняю тип на opened: «true» | «false», то и передать можно только «true» | «false» (то есть именно один из этих строковых вариантов и никакой другой строчный вариант не пройдет). А если я enum прокину, та и вовсе придется передавать свойство его.
Ничего не понял если честно. Что мешает вам в случае style components написать <div/>?
Если вы просто на своей стороне что-то переписываете, то конечно ничто не мешает. Но если юзаете готовый uikit, то будете все-таки компоненты из него юзать, верно?
Вот забыл я указать класс. Получаю ошибку что класс в стилях не используется. Ок, пусть я ещё и стиль забыл указать. Ну я ж не слепой, я же вижу что верстаю.
Вот это как раз проблема, для решения которой и юзается SC с типизацией. Если вы фулстек и проект полностью готовите в одно лицо, то конечно, делайте как хотите и как знаете. Но если вы работает в команде 350+ человек, то поверьте моему опыту, такое мало прокатывает уже. И там более четко делится на членов UI team и на конечных программистов. Когда я, как программист, программирую какую-то логику и хочу результат вывести в готовый сторонний компонент, я не хочу думать о том, какие там классы надо передать. Я хочу увидеть необходимые параметры с комментариями к ним и передать необходимое.
Вот когда-то и я делал примерно по вашему сценарию (он классический).
А сейчас я так не делаю. Если я что-то переименовал и зацепил, то я получил ошибку еще на уровне IDE, или на уровне прехука, или просто запустив скрипт проверки.
Более того, это работает и с импортируемыми сторонними компонентами, написанными в том же стиле. И это уже не черный ящик. И если сторонний компонент обновился и там что-то поменялось и зацепило у меня, мне не надо ходить с лупой по проекту или держать тестировщика, который целыми днями кликает проект (хотя где надо, я настраиваю cypress). И обновляюсь спокойно, а не в рулетку играю.
P.S. и все это — важная составляющая CI/CD. Когда я виливаю проект в гитхаб, там сробатвают экшены и все проверяется. И в большинстве случаев это решает проблемы типа «на моей тачке работало», особенно в случае использования воркспейсов и т.п…
поэтому вы можете смело переименовать это в трёх местах, и не трогать в оставшихся двух или что вы хотели там сделать
Так вот как раз этого-то и не нужно. И как раз это SC+TS и решает. Если я переименовал параметр, то я должен получить ошибку там, где я указываю несуществующий параметр и там, где я передаю не тот параметр (особенно это работает когда не просто Record<string, string> идет, как это часто в вашем примере происходит, а когда используются enum и прочие вложенные типы).
Есть и другой, менее критичный момент, но все же, типа
import cs from 'classname';
import {row, col} from './styles.scss';
И передача дальне в className этих самых полученных классов. Это немного решает проблему в том плане, что если в styles.scss поменялся селектор, то и в импорте можно получить ошибку. Но это не решает того, что должно передаваться в конечную верстку. То есть если у вас там должно быть
вы это тут никак не обеспечите проверку. Если разработчик забыл прописать нужный класс, то он просто его забыл.
А если я делаю SC с указанием нужного типа, то там будет все обязательно и будет отлично проверять.
Ну да. Разные специалисты используют разные инструменты и имеют разные знания. И это нормально. Именно поэтому я говорю чем мне нравится CS, но не говорю, что все остальное — от лукавого и фтопку всё. Каждому своё, и своё не каждому. А закусился как раз по причине того, что не нравится когда кто-то приходит и говорит «Вот только так надо, а остальное нафиг!».
По проекту в нескольких компонентах используется [data-opened]=«false».
Потом по какой-то причине переименовали в [data-closed]=«true». В пяти компонентах нашли этот класс и переименовали, а в друх забыли. И как вы это дело в таком случае будет отслеживать? Аргументы типа «нефиг переделывать» не принимаются.
Насчет того, что «типизация работает хорошо» — это вряд ли, для этого нужны другие инструменты (stylelint), которые проверяют корректность и параметров, и значений. За редким исключением в css-in-js такого вообще нет, либо проверяются только названия параметров.
Вот тут в ответ можно прям ваши же слова приводить:
Понимаю, чтобы эффективно чем-то пользоваться, требуется этому сначала обучиться, «выстрадать», придумать десять подходов, прочитать о сотне, найти самое лучшее… В программировании так фактически с каждым инструментом.
Вероятнее всего SC у вас не тот инструмент, который вы всячески изучили. Вот здесь мы с учеником разбирали конкретный пример реализации реакт-компонента со styled+параметры, то есть когда в SC передаешь параметры и они влияют на конечные стили. И там очень даже проверяется типизация. Если параметр обязательный, то не передать из реакта я не смогу (TypeScript будет ругаться), ровно как и передать не тот тип.
Есть еще много моментов (включая типизацию всей темы и автоподстановку вариантов в IDE даже для вложенных конструкций). CSS и т.п. этого не дают, там все просто живет своей жизнью.
Я для себя выбираю не просто хайповые вещи, а те, которые эффективно решают свои задачи и которые слишком объемные по своему коду, чтобы их можно было просто так быстро написать самому. И как по мне, redux не нужен совсем, его вполне заменяют нативные контексты реакта. А вот со стилями лично мне удобней именно SC. Вероятно, это потому что я не очень силен в SASS и т.п., то есть я не умею вот прям с нуля сразу заложить весь uikit и от него далее плясать по компонентам. Я чаще всего закладываю основу и потом постепенно наращиваю. И вот мне проще SC использовать, потому что у меня здесь типизация работает хорошо и проще покрывать cover-тестами. А все эти CSS-ы (пусть в less, пусть в sass, что угодно), я потом не понимаю что мне нужно после рефакторинга, а что нет. С SC у меня этой проблемы практически нет.
Все-таки собесились туда? И по результатам собеса развернулись и ушли, и вердикт: «серьезные ребята все-таки не идут»? Такое… Думаю, личного опыта с порога маловато, чтобы решать ходят туда серьезные ребята или нет. Такое больше похоже на «я обиделся». Мое же мнение: там всяких хватает, но и серьезные там есть точно. А собеседование — это не отражение реальности проекта, это может быть просто проверка на спектр знаний.
И да, лично я не юзаю ни redux, ни saga. Всегда был против подобных компонентов.
Зарегался.
Я вам говорю, что у меня на вход 3 параметра (может больше, может меньше) и у меня валидация всех параметров как внутри SC, так и в вызывающих компонентах. Вы мне в ответ шлете реакт-компонент с отрисовкой div-а с передачей в него CSS-селекторов. Да, понятное дело, что можно заточить отдельный реакт-компонент, суть которого будет только в принятии указанных параметров и формирования конечного набора className, стили для которых уже сформированы и тут типа тогда проверка будет всего и все и очень похоже на то, что в моем примере. Но вопрос: а будет ли тогда это сильно быстрее работать, если суть логики все равно выполняется в реакт-компоненте (то есть в рантайме, против которого вы и топите?). Это очень похоже на одно и то же. И воторой момент, о котором я говорил выше: использование других styled-компонентов в качестве селекторов. SC это поддерживает нативно. А в вашей реализации я что должен делать? if(props.children instanceof OtherComponent) {...}? Так чтоли? Зачем мне все это переписывать, если SC имеет из коробки?
Вот и получается, что вы говорите «Вам это не нужно, потому что в целом это поддерживается там, почти все». А я в ответ говорю «Мне того почти всего не достаточно, мне надо все». И я точно знаю, что мне надо, а не выбираю из чего-то незнакомого. Я и то и другое уже изучал и выбор осознанно сделан, даже если вы этого не понимаете.
И говорю еще раз: можно завязывать с обсуждением, я не хочу жевать одно и то же без толку.
Давайте уже завязывать. Вы меня не убедили (хотя я вас скорее всего тоже). Пусть хабравчане рассудят доводы За и Против.
Type '{ isOpened: boolean; }' is not assignable to type 'DetailedHTMLProps<HTMLAttributes, HTMLDivElement>'.
Property 'isOpened' does not exist on type 'DetailedHTMLProps<HTMLAttributes, HTMLDivElement>'.ts(2322)
От TS вообще почти ничто не зависит. Конечный JS все равно будет работать как JS, и можно забить на ошибки. Но TS вводят не для того, чтобы на него забивать, а чтобы он помогал, и чтобы было видно где что и как. И как раз в этом плане React+SC+TS — это как раз очень хороший союз. Если здесь TS исключать, то я бы вообще не стал спорить. Более того, так и сидел бы дальше на less.
Более развернутый вам пример, чтобы было понятней.
Нет, разница большая, в том, что у вас это два отдельных не связанных друг с другом компонента. Один генерит стили и кто хочет, тот пусть их и юзает, а не хочет — пусть не юзает. А кто хочет юзать, то пусть внимательно смотрят что именно передают. А в моем случае это два взаимосвязанных компонента, живущих совместной жизнью, и изменение одного влияет на другого.
Это из серии спора JS-разработчика и TS-разработчика. Вроде пишут практически на одном языке, а парадигмы совсем разные (по себе знаю, потому как не один год на чистом JS писал, прежде чем на TS перейти).
Отвечаю: нет, у меня очень даже не оторванный от жизни пример. Просто вы проблемы не видите, вот и решение вам не интересно. Так вот, в вашем случае проверка только на передачу класса, передан он или нет. При этом передаваемый класс (селектор) — это просто строка. Так вот, вы можете только проверить на то передан был класс или нет. При чем className="" — это как бы тоже передан, потому что параметр есть и он строковый, хоть это и пустая строка. А можно передать className=«dsf sdfhegr tr wefwef sdf dsf и еще много всего», и валидировать здесь нечего, есть значение и ладушки.
В моем же примере возможно использование нескольких отдельных переменных и конечный вызов может быть таким:
И я каждый параметр в отдельности могу валидировать и готовить под них нужные стили, а не просто проверять передан ли какой-то произвольный параметр или нет.
UPD: если интересно, вот сам исходный код:
github.com/Pivkarta/pivkarta.ru-2/blob/e9399f973243548b38e54d7760e1f3fce7554def/src/pages/_App/Layout/MainMenu/DropdownMenu/styles.ts#L19
github.com/Pivkarta/pivkarta.ru-2/blob/e9399f973243548b38e54d7760e1f3fce7554def/src/pages/_App/Layout/MainMenu/DropdownMenu/index.tsx
При чем в ретурн можно не одну строчку вернуть, а много CSS-кода, включая медиа-квери и т.п.
Если вы просто на своей стороне что-то переписываете, то конечно ничто не мешает. Но если юзаете готовый uikit, то будете все-таки компоненты из него юзать, верно?
Вот это как раз проблема, для решения которой и юзается SC с типизацией. Если вы фулстек и проект полностью готовите в одно лицо, то конечно, делайте как хотите и как знаете. Но если вы работает в команде 350+ человек, то поверьте моему опыту, такое мало прокатывает уже. И там более четко делится на членов UI team и на конечных программистов. Когда я, как программист, программирую какую-то логику и хочу результат вывести в готовый сторонний компонент, я не хочу думать о том, какие там классы надо передать. Я хочу увидеть необходимые параметры с комментариями к ним и передать необходимое.
А сейчас я так не делаю. Если я что-то переименовал и зацепил, то я получил ошибку еще на уровне IDE, или на уровне прехука, или просто запустив скрипт проверки.
Более того, это работает и с импортируемыми сторонними компонентами, написанными в том же стиле. И это уже не черный ящик. И если сторонний компонент обновился и там что-то поменялось и зацепило у меня, мне не надо ходить с лупой по проекту или держать тестировщика, который целыми днями кликает проект (хотя где надо, я настраиваю cypress). И обновляюсь спокойно, а не в рулетку играю.
P.S. и все это — важная составляющая CI/CD. Когда я виливаю проект в гитхаб, там сробатвают экшены и все проверяется. И в большинстве случаев это решает проблемы типа «на моей тачке работало», особенно в случае использования воркспейсов и т.п…
Так вот как раз этого-то и не нужно. И как раз это SC+TS и решает. Если я переименовал параметр, то я должен получить ошибку там, где я указываю несуществующий параметр и там, где я передаю не тот параметр (особенно это работает когда не просто Record<string, string> идет, как это часто в вашем примере происходит, а когда используются enum и прочие вложенные типы).
Есть и другой, менее критичный момент, но все же, типа
И передача дальне в className этих самых полученных классов. Это немного решает проблему в том плане, что если в styles.scss поменялся селектор, то и в импорте можно получить ошибку. Но это не решает того, что должно передаваться в конечную верстку. То есть если у вас там должно быть
вы это тут никак не обеспечите проверку. Если разработчик забыл прописать нужный класс, то он просто его забыл.
А если я делаю SC с указанием нужного типа, то там будет все обязательно и будет отлично проверять.
По проекту в нескольких компонентах используется [data-opened]=«false».
Потом по какой-то причине переименовали в [data-closed]=«true». В пяти компонентах нашли этот класс и переименовали, а в друх забыли. И как вы это дело в таком случае будет отслеживать? Аргументы типа «нефиг переделывать» не принимаются.
Вот тут в ответ можно прям ваши же слова приводить:
Вероятнее всего SC у вас не тот инструмент, который вы всячески изучили. Вот здесь мы с учеником разбирали конкретный пример реализации реакт-компонента со styled+параметры, то есть когда в SC передаешь параметры и они влияют на конечные стили. И там очень даже проверяется типизация. Если параметр обязательный, то не передать из реакта я не смогу (TypeScript будет ругаться), ровно как и передать не тот тип.
Есть еще много моментов (включая типизацию всей темы и автоподстановку вариантов в IDE даже для вложенных конструкций). CSS и т.п. этого не дают, там все просто живет своей жизнью.
И да, лично я не юзаю ни redux, ни saga. Всегда был против подобных компонентов.