>> Каюсь, ошибки видел. Но не разобрался, на что ругался...
Но проблема не в них, а в том, что понимания компонента не было.
Нет, проблема как раз в них. А точнее в том, что ты умалчиваешь за эти проблемы. Еще раз: одно дело писать логику, придумывать ее. Другое дело - решать чисто технические синтаксические задачи. Если ты видишь синтаксическую ошибку (про которую тебе подсказывает IDE), ты ее должен решить обязательно. Если ты не можешь ее решить, ты спрашиваешь как именно решить конкретно эту ошибку. Это чисто типовой подход. Нет никакого смысла пытаться написать какую-то логику, если у тебя имеются технические ошибки, из-за которых все равно ничего работать не будет. Если у тебя не работает логика, но технически все работает - это уже пол-дела. А если нет ни того, ни другого - то это полная бессмыслица. Работай над этим.
А так ты сейчас просто как страус прячешь голову в песок.
И зря избавился от DropdownMenuStyled. Я ранее тоже писал, что по неймингу лучше писать так: к имени компонента добавлять Styled, для стайлед-компонентов. Если у тебя компонент DropdownMenu, то для корневого элемента лучше заюзать DropdownMenuStyled, а вот внутри уже можешь что-то добавить еще (как тот же DropdownMenuListStyled (но не DropdownMenuBoxListStyled)). У тебя же сейчас получается
const DropdownMenuBoxListStyled = styled.ul
const DropdownMenuBoxStyled = styled.li
А я выше писал:
>> так как сейчас получается, что компонент с более коротким названием является вложенным в компонент с более длинным названием, что противоречит интуитивнопонятному неймингу
То есть ты переименовал, но пришел все к тому же: более короткое вложено в более длинное (к слову, я это заметил, только открыв исходники, хотя изначально по наименованию подумал про обратную вложенность). Плюс к этому у тебя DropdownMenuBoxStyled - это тег li и у тебя их много. Получается, у тебя много боксов в одном месте. Согласись, опять не интуитивно понятно. Я же советую так:
DropdownMenuStyled - это корневой ui,
DropdownMenuItemStyled - это li.
Поправь.
Каюсь, ошибки видел. Но не разобрался, на что ругался...
Но проблема не в них, а в том, что понимания компонента не было. Сейчас понял. Вроде бы.
Спасибо.
Дима, привет!
>> Когда он есть - то всё понятно, а когда сам пишкшь - всё как-то меняется...
Так ты смотри в то, что уже есть и что понятно, и делай по образу и подобию. Ведь общая структура типовая (index.tsx, interfaces.ts, styles.ts). И я ранее писал уже про то, чтобы стараться "Один файл - Одна сущность", то есть чтобы реакт-компонент в файле был только один. Ты забыл про это правило и дописал свой новый компонент в тот же файл к существующему компоненту. Скорее всего, если бы ты придержался этого правила, тебе было бы проще и меньше ошибок допустил был (потому что перед глазами меньше кода было бы и проще было бы видно границы).
И ты так и не ответил на счет ошибок, я несколько сообщений на этот счет написал. Мне не понятно видишь ты их или нет. Одно дело логику придумывать, другое дело решать чисто синтаксические ошибки типа "Здесь неожиданный тег". Ты очень многое не договариваешь.
Николай, привет!
Спасибо: изучаю код. Когда он есть - то всё понятно, а когда сам пишкшь - всё как-то меняется...
Коммит на изменение названия компонента: https://github.com/Pivkarta/pivkarta.ru-2/commit/7014b69d973ea8806587f3313905dbb9aa2ebd12
Ну вот ТС тебе говорит "Ты занимаешься фигней", и я с ним в целом согласен :)
Переходи к следующему уроку))
Просто интересно)
В моем случае нет конкатенации, потому что я складываю уже преобразованные в числа строки и у меня на выходе четко строки, то есть результат 15. В твоем же случае это походит на натягивание совы на глобус. Вот зачем тебе складывать числа со строками?
Получается мы принудительно получаем результат number и преобразуем строку в число, но по логике вычисления там включается конкатенация и результат этого выражения должен быть 105, насколько вообще правильно в данном случае так делать или это все-таки зависит от задачи?
Может можно все-таки что-то сделать не ломая логику выражения?
Здесь, думаю, бага тайпскрипта. С одной стороны логично, что он тебе говорит, что "Нельзя строку или число сложить со строкой или числом" (потому что складывать надо число с числом). С другой стороны TS вполне кушает такое:
const a: string | number = 1;
const b: string | number = '2';
const z = a + b;
Он понимает, что z на выходе будет только строка (потому что число плюс строка на выходе строка).
При этом даже так работает:
interface MyArray<T> {
reduce<T>(fn: (arg:T) => T): T;
}
let arr = [1, 2, 3, 4, '5'];
let results = arr.reduce((sum, current) => 1 + '2', 0);
results
То есть мы явно складываем число и строку и ТС это не парит.
Для тебя выход: или использовать только числа, или если ты допускаешь, что могут приходить строки, но это все равно числа, то парсить их.
interface MyArray<T> {
reduce<T>(fn: (arg:T) => T): T;
}
let arr = [1, 2, 3, 4, '5'];
let results = arr.reduce<number>((sum, current) => sum + (typeof current === "string" ? parseInt(current) : current), 0);
results
Обрати внимание, что <number> в такой конструкции обязателен, потому что reduce сам по себе тоже дженерик, и в него можно передать какой тип ожидается в результате. Если ты не указываешь явно, то он берет из входящих параметров. Так как у тебя на входе массив чисел или строк, то он допускает, что sum тоже число или строка, и тоже ругается на то, что его нельзя суммировать. Указав <number> мы ему сообщаем, что результат у него четко number, и тут уже reduce будет требовать, чтобы каждая итерация у тебя возвращала четко number и будет считать, что sum тоже всегда number.