Comments 27
MyComponent = ({ placeholder = '', style, <b>...otherProps </b>}) => {
style={{
border: `1px solid ${placeholder ? 'salmon' : '#333'}`,
<b>...style</b>,
}}
{<b>...otherProps</b>}Имхо это ужасно не понятно что идет в сам компонент и дальше по цепочке, в идеале лучше иметь не много пропсов, или лучше заюзать тайпскрипт и выделить пролетающие пропсы в отдельный объект
} from '../../../../../../../../../../components/Breadcrumb'
render={(results) => (
<BreadcrumbFishes>
{({ breadcrumbFishes }) => (
<BreadcrumbLeftOvers.Provider>
<BreadcrumbHotdogComponent>
<Expander>
<BreadcrumbText>
<BreadcrumbAddict>весело тем кто будет разбираться в таком коде :)
../../../../../../../../../../Это шутка?
Относительные пути работают абсолютно всегда, пока сами сорсы лежат вместе, и рефакторятся автоматически любой средненькой IDE.
...
<BreadcrumbAddict>
<pre>
<code>{JSON.stringify(results, null, 2)}</code>
</pre>
</BreadcrumbAddict>
Может лутше подготавливать все данные заранее?
И вообще, Вы веть должны понимать — react (как и vue, svelte, etc.) лиш «рисовалка», и гораздо важнее уметь правильно разделять приложение на независимые слои, с минимальными «точками соприкосновения», про это уже писали, правда не в контексте «фронтэнда».
Если правильно понял то вам нужен этот пакет ️ https://github.com/pahen/madge
Он умеет кушать на вход ваши модули а на выход рисовать картинку зависимостей, помечая кольцевые красным цветом
Написание чистого кода (...) становится обязательным на определённом этапе карьеры программиста. Особенно (...) когда программист пытается найти свою первую работу.
Нууу, удачи, как говорится, всем студентам писать чистый код еще до своей первой работы… :)
let result
if (variant === 'h1') result = styles.h1
else if (variant === 'h2') result = styles.h2
else if (variant === 'h3') result = styles.h3
else if (variant === 'h4') result = styles.h4
else if (variant === 'h5') result = styles.h5
else if (variant === 'h6') result = styles.h6
else if (variant === 'title') result = styles.title
else if (variant === 'subheading') result = styles.subheadingO_o не делайте так никогда, это пример плохого кода. Используйте switch в подобных конструкциях.
const getStyles = variant => {
switch (variant) {
case 'h1':
return styles.h1
case 'h2':
return styles.h2
default:
return styles.default
}
}
const getStyles = variant => (variant in styles ? styles[variant] : null)После подобного и
../../../../../../../../../../, невозможно воспринимать статью всерьёз. Webpack alias, автору для справки.Webpack alias, автору для справки.
Вы только не забывайте, что про webpack alias будет знать только вебпак. А не, например, IDE.
const getStyles = variant => (variant in styles? styles[variant]: null)
А потом этот код попадёт под минификацию и станет тыквой. Switch — нормально во всех случаях, а вот этот вариант — далеко не во всех.
А потом этот код попадёт под минификацию и станет тыквой.
Если ваша минификация калечит даже такой код, то первое что вам стоило бы сделать — поднастроить её или удалить к чертям. У всего есть свои пределы. Минификация не должна влиять на то, как вы пишете код. Ну за редким исключением вроде штук вида dead code elimination.
ваша минификация
Вы из тех, кто кроме готовых сайтиков всей кучей никогда ничего не писал?
Проблема кривой минификации может быть совсем даже не у вас, вот в чём соль. А у людей, использующих ваш код. И не всегда это такие люди, которым можно сказать «проблема на вашей стороне».
Сделать всё как надо у вас — никогда не проблема, во фронтэндском CI настраивается примерно всё, а если вдруг не настраивается, то есть другие инструменты, где таки да. А вот сделать так, чтоб ваше творение жило и работало во всех сценариях использования, в том числе не ваших, и в том числе и не особо правильных — это чуточку другой разговор.
Какой-то нелепый переход на личности (рекомендую так больше не делать здесь) и несвязный текст. Что вы хотели сказать? Поясните детальнее. Моя позиция простая: минификация кода (uglifyjs наверное в вашем случае) НЕ ДОЛЖНА ломать код. Т.е. не должна переименовывать литералы и не должна переименовывать ключи объектов. Если она так делает, то она сильно агрессивная и ломает работу тех продуктов где используется (пока разработчики не выловят сами все эти проблемные места). У вас есть по этому поводу возражения?
Т.е. я не против того чтобы минификатор менял длинные имена на короткие двубуквенные, но он должен делать это ТОЛЬКО и ТОЛЬКО тогда когда он гарантирует тот факт, что это ничего не поломает в коде. И никак иначе. Выгода в полтора процента размера бандла однозначно не окупиться мириадой багов, которые может вызвать такое поведение минификатора.
Какой-то нелепый переход на личности
Да ровно такой же, каков и ваш.
Что вы хотели сказать? Поясните детальнее.
Поясняю по буквам: пайплайн сборки не всегда полностью у вас под контролем, иногда его часть на стороне.
Если она так делает, то она сильно агрессивная и ломает работу тех продуктов где используется (пока разработчики не выловят сами все эти проблемные места). У вас есть по этому поводу возражения?
У меня — нет. Возражения могут быть у тех, кому, например, вы поставляете вашу либу. А на ваши заявления о том, что они сами виноваты — они всегда могут ответить «нет, не мы», и не всегда у вас будет возможность продолжать эту линию аргументов.
Вы так не делали и у вас подобных случаев не возникало? Ну поздравляю.
Т.е. я не против того чтобы минификатор менял длинные имена на короткие двубуквенные, но он должен делать это ТОЛЬКО и ТОЛЬКО тогда когда он гарантирует тот факт, что это ничего не поломает в коде.
А я вам о том, что минификатор не всегда на вашей стороне. И можно написать так, что минификатор в принципе ничего не поломает (с какими угодно настройками), а можно написать так, что может быть и поломает. И разницу между тем и этим — не всегда нужно учитывать, но вообще неплохо бы хотя бы осознавать.
И можно написать так, что минификатор в принципе ничего не поломает (с какими угодно настройками)
Нет, нельзя. Достаточно сократить до двух букв какой-нибудь window или document — и всё поломается как бы вы не писали код.
А я вам о том, что минификатор не всегда на вашей стороне.
Нет никаких объективных причин принимать в рассчёт такие случаи, когда на чужой стороне стоит неадекватно настроенный минификатор, который ломает даже такие тривиальные случаи.
Ну, ок, исключение — когда вы пишете B2B продукт под конкретную контору, где время остановилось, страшное легаси и жуткая бюрократия, поддержка IE8 & Silverlight. В этом случаем это наименьшая из ваших проблем да.
Вы так не делали и у вас подобных случаев не возникало?
Я вам даже больше скажу — и никогда не возникнет. Подобными извращениями ("перетюненный" uglifyjs) баловались люди года 4 назад. У них стали ломаться ангуляры и тонны других библиотек. Потом пришло осознание простой истины — сама затея пережимать ломая код идиотична по своей природе.
P.S. предлагаю на этом наш "холивар" закончить. Ваша точка зрения мне более чем понятна.
Ну, ок, исключение — когда вы пишете B2B продукт под конкретную контору, где время остановилось, страшное легаси и жуткая бюрократия, поддержка IE8 & Silverlight. В этом случаем это наименьшая из ваших проблем да.
К слову говоря, я с вами тут общаюсь вовсе не по следам абсолютно выдуманной ситуации. Так что да, исключения бывают. И не такие уж они исключения в определенных кругах.
P.S. предлагаю на этом наш «холивар» закончить.
Надо же, людям пишешь «позвольте, но не всегда всё так просто, как вы считаете», а они это холиваром потом называют.
Почему бы не упростить вот так:
const result = styles[variant];У автора написано вот такое:
const removeFalseyImages = (images = []) => images.reduce((acc, img) => (img ? [...acc, img] : acc), [])
Но я но согласен! Такое нужно переписать вот так
const removeFalseyImages = (images = []) => images.filter(Boolean);
14 советов по написанию чистого React-кода. Часть 1