Каюсь, ошибки видел. Но не разобрался, на что ругался... Но проблема не в них, а в том, что понимания компонента не было. Сейчас понял. Вроде бы. Спасибо.
Дима, привет! >> Когда он есть - то всё понятно, а когда сам пишкшь - всё как-то меняется... Так ты смотри в то, что уже есть и что понятно, и делай по образу и подобию. Ведь общая структура типовая (index.tsx, interfaces.ts, styles.ts). И я ранее писал уже про то, чтобы стараться "Один файл - Одна сущность", то есть чтобы реакт-компонент в файле был только один. Ты забыл про это правило и дописал свой новый компонент в тот же файл к существующему компоненту. Скорее всего, если бы ты придержался этого правила, тебе было бы проще и меньше ошибок допустил был (потому что перед глазами меньше кода было бы и проще было бы видно границы). И ты так и не ответил на счет ошибок, я несколько сообщений на этот счет написал. Мне не понятно видишь ты их или нет. Одно дело логику придумывать, другое дело решать чисто синтаксические ошибки типа "Здесь неожиданный тег". Ты очень многое не договариваешь.
Николай, привет! Спасибо: изучаю код. Когда он есть - то всё понятно, а когда сам пишкшь - всё как-то меняется... Коммит на изменение названия компонента: https://github.com/Pivkarta/pivkarta.ru-2/commit/7014b69d973ea8806587f3313905dbb9aa2ebd12
Ну вот ТС тебе говорит "Ты занимаешься фигней", и я с ним в целом согласен :) Переходи к следующему уроку))
В моем случае нет конкатенации, потому что я складываю уже преобразованные в числа строки и у меня на выходе четко строки, то есть результат 15. В твоем же случае это походит на натягивание совы на глобус. Вот зачем тебе складывать числа со строками?
Получается мы принудительно получаем результат number и преобразуем строку в число, но по логике вычисления там включается конкатенация и результат этого выражения должен быть 105, насколько вообще правильно в данном случае так делать или это все-таки зависит от задачи? Может можно все-таки что-то сделать не ломая логику выражения?
Здесь, думаю, бага тайпскрипта. С одной стороны логично, что он тебе говорит, что "Нельзя строку или число сложить со строкой или числом" (потому что складывать надо число с числом). С другой стороны TS вполне кушает такое: Он понимает, что z на выходе будет только строка (потому что число плюс строка на выходе строка). При этом даже так работает: То есть мы явно складываем число и строку и ТС это не парит. Для тебя выход: или использовать только числа, или если ты допускаешь, что могут приходить строки, но это все равно числа, то парсить их. Обрати внимание, что <number> в такой конструкции обязателен, потому что reduce сам по себе тоже дженерик, и в него можно передать какой тип ожидается в результате. Если ты не указываешь явно, то он берет из входящих параметров. Так как у тебя на входе массив чисел или строк, то он допускает, что sum тоже число или строка, и тоже ругается на то, что его нельзя суммировать. Указав <number> мы ему сообщаем, что результат у него четко number, и тут уже reduce будет требовать, чтобы каждая итерация у тебя возвращала четко number и будет считать, что sum тоже всегда number.
В общем, ты пока явно плохо видишь границы реакт-компонентов. Напомню: у нас функциональное программирование и реакт-компонент сейчас - это просто функция. Редактировать то, что у тебя сейчас сделано - смысла мало. Там каша получилась. Вот ПР отправил: https://github.com/Pivkarta/pivkarta.ru-2/pull/3. Принимай и разбирай (что и как работает). Так же оставил тебе задачку: >> (там, скорее всего, придется переименовать компоненты DropdownMenuBoxStyled и DropdownMenuStyled, чтобы было логичней, так как сейчас получается, что компонент с более коротким названием является вложенным в компонент с более длинным названием, что противоречит интуитивнопонятному неймингу) Вот перемеименуй компоненты и шли коммит на ревью.