Курс JS 2.0: itgid.info/course/javascript-2 Курс HTML для JS разработчиков: itgid.info/course/html Телеграмм канал: t.me/itgid_info Телеграмм автора: telegram.me/alex_luschenko
В 5 сниппете можно еще прибавлять пустую строку. Например, let n5 = 10; n5 + ""; на выходе получим строку. Ну или банальный способ передать значение в String(n5).
Отличное видео! Я когда учился и переписывал сторонний код, то частенько встречал эти сниппеты, но приходилось догонять их по контексту. Спасибо, всё равно, открыл для себя что-то новенькое и как повторение!
мне например очень не нравится конструкция "свитч" в жс. поэтому часто заменяю его объектом. например вместо свитча: const move = function (direction) { let code; switch(direction) { case 2: code = 'Game_Character.ROUTE_MOVE_DOWN'; break; case 4: code = 'Game_Character.ROUTE_MOVE_LEFT'; break; case 6: code = 'Game_Character.ROUTE_MOVE_RIGHT'; break; case 8: code = 'Game_Character.ROUTE_MOVE_UP'; break; } return code } написать так: const move = function (direction) { let code = { '2': 'Game_Character.ROUTE_MOVE_DOWN', '4': 'Game_Character.ROUTE_MOVE_LEFT', '6': 'Game_Character.ROUTE_MOVE_RIGHT', '4': 'Game_Character.ROUTE_MOVE_UP' } return code[direction]; } или даже так const move = function (direction) { return { '2': 'Game_Character.ROUTE_MOVE_DOWN', '4': 'Game_Character.ROUTE_MOVE_LEFT', '6': 'Game_Character.ROUTE_MOVE_RIGHT', '8': 'Game_Character.ROUTE_MOVE_UP' }[direction]; }
@@NeveraIs По читайте "чистый код". Свитч всегда проигрывает блоку из ифов. А если есть возможность завернуть сложное условие в объект, то это стоит того. Дефолт прикрутить можно либо отдельной функцией, либо ещё одной проверкой. Это прозначно и очевидно. А если не зафакапать нейминг, то читаться код будет просто с листа, даже не нужно нырять в этот объект - его поведение очевидно.
@@NeveraIs тут абстрактная функция движения персонажа в четырех направлениях. если передается движение которого нет, то персонаж никуда не двигается, что логично и в принципе можно так и оставить - возвращать undefined. но если все-таки нужен дефолт, то тоже делается стандартной конструкцией языка через "или": const move = function (direction) { return { '2': 'Game_Character.ROUTE_MOVE_DOWN', '4': 'Game_Character.ROUTE_MOVE_LEFT', '6': 'Game_Character.ROUTE_MOVE_RIGHT', '8': 'Game_Character.ROUTE_MOVE_UP' }[direction] || false; } а для лучшей читаемости: const move = function (direction) { let code = { '2': 'Game_Character.ROUTE_MOVE_DOWN', '4': 'Game_Character.ROUTE_MOVE_LEFT', '6': 'Game_Character.ROUTE_MOVE_RIGHT', '4': 'Game_Character.ROUTE_MOVE_UP' } return code[direction] || false; }
@@GreenHappyHelix, Объект мб лучше вне функции определить, чтобы он каждый раз при вызове не создавался const routes = { '2': 'Game_Character.ROUTE_MOVE_DOWN', '4': 'Game_Character.ROUTE_MOVE_LEFT', '6': 'Game_Character.ROUTE_MOVE_RIGHT', '8': 'Game_Character.ROUTE_MOVE_UP' }; const move = direction => routes[direction] || false; Блин, не заменил, что коммент был год назад оставлен, ахах
у меня не большой опыт но по моему #4 сниппет объясняется не правильно , если y первого аргумента (который стоит с лева оператора &&) значение которое преобразуется в true тогда выполнится и второй аргумент, если false то не выполнится, то есть если нам надо выполнить код когда у нас 4 а не 3 то это не подойдет, а если код не надо выполнить в случае ложного значение то сниппет сработает.
Александр, здравствуйте. Подскажите пожалуйста, часто вижу при в видео обучающий при разработке приложений обрабатывают ошибки кидая исключения типа trow new Error или Exeption и тд. Эти записи обработки ошибок trow new Error и тд., чисто для разработчиков и для тестов, а потом они меняют их на визуальный вывод для клиента , чтоб приложение не ломалось при попадании на исключения, ведь так?
В 4 примере, это две совсем разные вещи! В первом случае проверка идет на 100% нужное значение, а в укороченом втором варианте просто лижбы что было в значении т.е. неважно что лижбы не null, undefinet, false
в 10 сниппете, если хотите проверить переменную именно на null и underfined, то можно использовать variable ?? по_умолчанию это позволит избежать случаев, когда присвоено значение, которое при конвертации в Boolean становится false, к примеру число 0
В 5ом примере интерполяция лучше т.к. при вызове toString() будет ошибка, если значение null или undefined. По сути `${n}` будет эквивалентно n == null ? n : n.toString()
Конечно спору нет это видео очень крутое, с оговоркой для продвинутых в js, но не для новичков и кто учиться программированию на js! Лучше написать по простому, чем коротко и не читаемо!
не понял зачем 6-ой снипет если можно просто: n6 === 7 ? f6_1() : f6_2() кол-во символов одинаковое, но при этом приведенная мной строчка стандартная конструкция языка, которая даже новичка не застанет врасплох, в отличии от приведенного в видео снипета
@@itgid это да. например этот код из видео часто используется и в проде для самовызывающихся анонимных функций - оборачивают анонимную функцию в скобки чтобы она стала функциональным выражением, а затем вызывают с помощью скобочек в конце
Александр, данное видео вызвало бурю комментариев и разборов, что полезно как для продвижения канала так и для зрителей, читая комменты можно подчерпнуть новое. Обязательно продолжайте такую тематику, не вкоем случае не старайтесь делать ролики нейтральными и безвкусными.
Из годного то что сам +/- юзаю: 3-5, 8-10. 1 и 2 - ну не то что ужас, кому надо погуглит, но как по мне экономия на спичках, читабильность > красоты. 6 и 7 это ужасно. 6 - если есть опыт то на подсознание вызов функции это имя со скобками. В процессе чтения ты должен дочитать строку до конца, преодолеть начальное удивление, вспомнить что делают эти функции (названия в помощь). Это когнитивная нагрузка + 100500. От 7-го тоже плевался бы. Слишком не очевидно. Хочешь кинуть исключение? Кинь его в функции, это в разы более прозрачно. + Даже те сокращения которые норм нужно с умом использовать. Хотя естественно в первую очередь роль играют договоренности внутри команды. Если всем норм и все понимают то допускаются любые сокращения
Так 5 сниппет не дает результат строчный как переменной. Это хорошо только для упрощения вывода, когда в одной строке много переменных и кусков текста и не нужно миксовать скобки и запятые. так что применение toString и ${n} разное
не стоит использовать сниппеты, которые приводят к сайд-эттектам. То есть вы в примере используете строгое равенство и тут же сниппеты с сайд-эттектами. Плюс принципы минификации приводят не к улучшению, а к ухудшению читабельности. Тернарный оператор не рекомендуют использовать вместо условия для вызова функций, крайне желательно использовать его только для задания значений в переменной. Но эти замечания могут быть неактуальны, если в команде придерживаются такого же стиля, главное в хорошем коде - легкость поддержки и работоспособность (при прочих равных)
Хороший комментарий. В частности, да. Если вы занимаетесь бэкэндом на js и никого, кроме спецов в коде появляться не будет, то можно договориться и использовать сниппеты. Если это фронт, в какой-то cms то сниппет, вместо читаемой строки - повод бить по рукам. Код должен быть не красивым или коротким, а понятным, читаемым и поддерживаемым.
@@itgid там был список где то 17 снипетов, перевод какой то зарубежной статьи, включая все что в видео, удивило просто что только читал ее и тут видео с тем же самым, называлась она правда не снипеты, но холивара в комментах много было кто что считает лучше использовать и что лучше не использовать
Согласен с комментаторами ниже. Да сниппеты это классно, но не в обиду будет сказанно, мне как новичку они кажутся немного бессмысленными. Как пример, шестой сниппет.лично мне не понятно зачем писать console.log( n5.toString() ); если можно просто написать console.log( String(n5) ); хотя сниппет и выглядит более круто, но согласитесь, когда смотришь на второй вариант все ну прям до безобразия элементарно. ))
Как это не смешно, но js это объектно ориентированный язык. Вы работаете с объектами. Кроме того, у каждого объекта есть родитель, который отмечен как proto. И у него есть огромное количество методов через множественное наследование. Любая переменная, на самом деле объект и у ней есть свойство lenth которое можно вызвать непосредственно и тот же метод toString(). Так что в парадигме ООП этот метод более правильный. Когда вы делаете String(n) то создаёте новый объект только ради того, чтобы взять строковое значение. Это менее правильно, но не является ошибкой. Запись в обратных ковычках используется для динамических преобразований. Например, через такую запись можно выводить прогрессбар проценты в консоль, во время выполнения скрипта. И занчение будет подменятся динамически. Вы видите это каждый раз, когда устанавливаете библиотеку через npm. Все способы имеют место быть и своё право на жизнь. Другой вопрос, что хорошо читается, а что нет. Если вы везде используете обращение к свойствам и методам класса, а тут вдруг создали объект "из ни откуда" это несколько ломает восприятие и чтение кода. Легко читается однообразный код. Если в стилистике каша, то это будет сбивать.
@@ivantrubchaninov1844, строка новая всё равно создаётся. Потому что строка это примитив, а мутировать можно только объекты (просто объекты, массивы и функции)
