#17 Криптономикон: рефакторинг - Vue.js: практика
ฝัง
- เผยแพร่เมื่อ 25 ก.ย. 2024
- Код урока: gitlab.com/vue...
Материалы для самостоятельного изучения:
ru.vuejs.org/v...
Присоединяйтесь к нашему сообществу в Telegram t.me/vuejs_club
---
Видео создано благодаря подписчикам проекта на нашем Patreon.
/ javascriptninja
Волшебный урок. Если честно, пойду переписывать приложения после этого. Очень важный момент что вложили как нужно размышлять при написании. Огромное спасибо!
Самое доходчивое объяснение computed и watch. Жаль не успел начать вместе со всеми, но надеюсь еще нагнать)
Илья, спасибо большое!
Это божественно!
Недавно на работе делал свое первое приложение на Vue. Смотря твой курс подмечаю очень много крутых вещей, понимания которых очень не хватало в момент написания приложения.
Очень хорошо обьяснили про watch и computed, вроде и юзал их но до конца не понимал концепции)
тут все по полочкам) спасибо Вам!)
Я уже почти год во vue.js и думал что понимаю что такое computed и как его использовать, но после этого выпуска меня будто молнией долбануло. Илья, огромное спасибо за такое прекрасное пояснение того что такое на самом деле "вычисляемое свойство", это просто лучшее объяснение!
Смотрю спустя год, ураганный курс! Большое спасибо!!!!
Офигенное видео! Очень понравилось объяснение computed и watch.
Спасибо что выкладываете на Ютуб
В процессе просмотра этого видео понимаю, как сильно в компании нам не хватает парного программирования. Спасибо за курс!
Начало на 11:11
Отличный урок!
Спасибо огромное уважаемому автору.
мало что понимаю, но не могу оторваться)))
Теперь понятнее стало?)
@@ОлегМельник-ф5ы yes
огромное огромное спасибо=))) очень и очень полезный курс=)) спасибо еще раз!
Спасибо за полезный контент
Илья, попотерял сон после того, как увидел ваш подход к использованию watch)
С одной стороны такой подход супер декларативный и по полной использует возможности vue.
С другой он размазывает логику компонента (приложения?) по разным местам в коде.
Например у меня в проекте есть компоненты в которых есть бизнес логика состоящая из нескольких взаимосвязанных шагов. Зачастую они последовательно меняют стейт. Кроме этой логики есть еще всякий шум вроде handleClick, openModal, isLoading, fetchFilteredComponents и т.д. После просмотра вашего стрима я понимаю, что бизнес логику, вместо одного императивного метода можно разобрать на несколько watch методов. Станет декларативно, но будет сложнее проследить как раз эту важную цепочку событий. Т.е. прочитать один длинный метод против анализирования и выстраивания у себя в голове взаимосвязей между разными watch.
Очень интересно ваше мнение по поводу этой проблемы разрозненности кода\логики в options api. И может какие-нибудь советы кроме использования composition api)
Я точно композишн не посовету
Критерий выноса в watch очень простой - если ТРИГГЕРОМ является изменение данных (а не вызов кнопки и так далее) - это в watch
А разрезать метод на несколько вотчей просто потому что мы можем, при том что в бизнес-требованиях эта логика "Когда кликаем по кнопке делаем раз, два, три" - плохо
@@JavaScriptNinja Спасибо за ответ. Во время стрима, мне показалось, что вы довольно безапеляционно утверждали, что отдельный watch это всегда хорошо. Но все таки, как обычно, "it depends" )
@@PhotographerRoman нет, могу даже дать таймстампу
@@JavaScriptNinja поверю на слово)
Спасибо! Стало понятнее как и когда использовать Watch
Заставка до 4:43
Красавец! Все видео на одном дыхании смотрю!
Насчет TS'a, а как вы работаете с данными, которые состоят из сущностей, которые состоят из сущностей, которые состоят из значений, а каждое значение может быть только строго определенным из списка? Каждый раз смотрите в контракты?
Спасибо за урок!
В конце видео сложилось впечатление, что все дружно хотели внушить Илье, что ТС это круто)
Это потому что Илья знает что-то о TS, чего не знают все, и не делится. Надеюсь, однажды расскажет или ссылку добавит.
@@yoloopen да он на каком-то выступлении рассказывал про проблемы тс)
@@yoloopen Илья про это регулярно рассказывает в чате, просто надоело уже :)
Можно ссылку на видео, где Илья рассказывает о проблемах ts?
@@ДмитрийНевежин-х2л нету такого видео
Спасибо! 👍
1:05:10 я бы использовал early return. Если текущая страница
TIL: использовать watch вполне себе норм. После чтения документации Vue осталось впечатление, что нужно по максимуму использовать computed, а к watch прибегать в крайних случаях.
Документация права. Все что можно рассчитать с помощью computed - стоит делать с компьютедами
1:01:16 дублирование в watch
Спасибо
отличное видео, спасибо, про ТS ничего не знаю, но если Илья говорит, что это зло - полностью с ним согласен.
P.S. ТС - редиска :))
Та за шо? Team Speak нормальная же программа.
@@ИмяФамилия-э4ф7в :D
11:53 - да норм. Бывает))))
вотчер paginatedTickers срабатывает при загрузке страницы с пустым значением массива всегда и соответственно минусует 1 от той страницы, которая была запомнена в урл(протестить можно перейдя на page=2 и обновив страницу)
Спойлеры :)
какая милая бажина, спасибо)
59:10 Подскажите, есть ли разница между Вашей реализацией и добавлением опции deep: true для наблюдателя? И какой из подходов предпочтительнее? В документации явно указывают на использование данной опции при отслеживании мутаций массива.
спасибо.
В логике функции уменьшения страницы после фильтрации недостаток: если мы были на 3-й странице, а в результате фильтра осталась одна, то произойдет переход на 2-ю страницу и повторный вызов кода. Не проще сразу по количеству filteredTickers определить количество страниц и перейти на последнюю?
Простите за вопрос, который не относится к веб-программированию вообще, а это у вас стандартный терминал от windows ? или какой-то другой
4:44 начало видео(вопросы из чата)
11:07 работа над ошибками автора в своих видео
Одна из причин использовать composition api это как раз и отказ от миксинов. Ну и TS более подходит для него. Options Api - это для староверов, которые привыкли и не хотят переходить на другую парадигму )))
Я не люблю императивные парадигмы и стараюсь не тащить их в код без надобности
@@JavaScriptNinja Ну так а чем composition api более императивный за options api? Наоборот в нем масса преимуществ, как например можно импортить только то что используешь, тем самым уменьшая размер бандла. Использование реактивности во внешних модулях (аля-миксин). Всех преимуществ и не назову, потому что активно уже на vue не пишу. Но то, что однозначно имеет огромные "+" и новые проекты нужно на нем писать, это однозначно. Но в угоду совместимости и консервативности сообщества, options api делают каноничным.
@@Богдан-р4ы1э Это ваша позиция :) Я ее понимаю
Про императивность
Composition API - я шаг за шагом, последовательно создаю структуру моей ViewModel. Чтобы осознать ее мне надо до конца выполнить код setup в своей голове
Options API: декларативно описана вся структура VM, я могу не вникать в детали реализации
Реактиность во внешних модулях никак не привязана к composition API, более того Vue.observable есть даже в 2.6 для объявления реактивных данных.
Это распространенная позиция. К сожалению, как показывает практика, применением реактивности "по умолчанию" везде приводит к "прекрасному" графу зависимостей между композаблами, который становится крайне сложно отследить
Именно поэтому я считаю применение composition API в большинстве случаев неоправданным
C template compiler реально боль, когда возникает ошибка и он не подсказывает где именно. Я надеялся, что это исправят во Vue3, но нет. Обидно.
Из за Watch - tickers, у нас получается следующая картина:
При загрузке страницы -> мы достаем тикеры из localStore -> кладем их в this.tickers -> срабатывает watch -> Сохраняет эти же тикеры в localStore.
Это нормальная практика? Или это плохой код который потом будет дальше рефакториться?
Это можно поправить одним ифом, но в реальном проекте не стоит внимания
33:03 Мультикурсор вышел из чата
Совсем не согласен с тем, что TS бесполезен. Наличие типов и интерфейсов, как минимум когда возвращаешься к коду который трогали несколько месяцев назад. Помогает вспоминать, а что же там по идее должна возвращать функция или что это вообще за класс
+ добавляет private и protect в классы
Хотя в целом соглашусь, что в TS не хватает нормальной проверки типов (если сделают будет вообще бомба)
Еще enum тоже неплохая штука, помогает при работе с vuex (мы храним в enum строки, которые нужно передать, какое событие или мутацию вызвать), но в целом соглашусь ,что можно просто использовать обьект.
PS
в nestJS видел классную возможность написание классов которые будут выступать в качестве интерфейсов (очень удобная штука, которая позволяет валидировать поля как угодно)
А что если метод что то рассчитывает и возвращает значение , основываясь на состоянии приложения но еще и смотрит в DOM на высоту div. Такую ф-цию лучше оставить в methods ? Ведь перенос в computed закешируется и при изменении высоты computed не будет этого учитывать.
Он и в methods не очень хорошо будет смотреться (впрочем мы еще не касались рефов)
Спасибо за урок! При повторном нажатии на тикер, график сбрасывается. С первого взгляда больше перезаписи на другое значение не нашел. Если поставить условие обнуление графика: если новый тикер не равен текущему, то не сбрасывается. Если значение перезаписывается на такое же, то умный VUE не должен выполнять действие? Видать накосячил в домашке, буду искать)
хм, заработало без исправлений. Костыль убрал, можно в прод
Доброго. А можно все таки ссылку на этого Артема, курс инженера или сразу боли тайпскрипт?
Нет :)
Илья, Если вам не сложно, можете скинуть ссылку на видео "Артема, которое перевернуло представления о TС"?
Нет, это с курса js-инженер
@@JavaScriptNinja понятно, спасибо
Подскажите пожалуйста, как решить данную проблему? Когда прописываю данную функцию:
filteredTickers() {
return this.tickers.filter(ticker => ticker.name.includes(this.filter));
},
получаю ошибку в консоли - Uncaught TypeError: Cannot read properties of undefined (reading 'includes')
Пробовал скопировать код урока, такая же беда, не может распознать данный метод.
ticker.name на каком-то этапе у тебя равняется undefined - то есть какой-то тикер у тебя без поля "name"
@@serhii3328 Спасибо, я уже нашел решения. Так как проверки не было ранее реализовано нафигачил левые пустые тикеты и метод includes начал ругаться. Все тикеты поудалял и повесил проверку на валидность в фильтре ticker.name?.includes(this.filter)); и только после начало нормально работать.
где можно посмотреть/почитать про проблемы TS?
Тут ещё можно зайти с другой стороны, что он не так уж много проблем решает.
А если заказчик решит открыть приложение в другом браузере? Как быть с local storage? Как я понимаю, там никаких данных не будет.
Это вообще не проблема держу в курсе. В реальных проектах это делется через БД
Вопрос - на this.selectedTicker стоит watch и через каждые 5 секунд по SetInterval его поле price обновляется, но watch не срабатывает. В тоже время this.pageStateOptions срабатывает при любом обновлении его полей. Почему?
Прочитайте про опцию deep у watch
@@JavaScriptNinja спасибо, но в обоих случаях же мы не используем deep
@@dimariskhakov1057 при обновлении "полей" каждый раз генерируется новый pageStateOptions, поэтому там deep не нужен
@@JavaScriptNinja спасибо
А если метод не используется в шаблоне, есть ли смысл его делать computed?
Да, вполне, если всё что он делает это возвращает значение
Не попал на стрим, к сожалению. Вопрос к графику, там ведь в апи есть возможность загружать исторические данные для валют, почему бы не использовать эту опцию?
Просто потому что такая задача изначально не стояла
А есть ли итоговый код рефакторинга?
Да, в гите
Можно ли стать веб разработчиком без хорошего знания JavaScript?
нет
Пойти в бэк
Можешь стать хорошим кассиром без хорошего знания JS
40:33
Тайпскрипт не добавляет ценности? Серьезно? Когда в апе десятки тысяч строк кода, сотни разных типов объектов ts выгребает сотни ошибок на этапе разработки, а не в продакшене. Если вам не помогает ts - значит вы его не правильно используете.
Люблю радикальные убеждения. Да, я утверждаю что время затраченное на тайпскрипт даёт сильно меньше ценности, чем то же время затраченное на написание тестов
@@JavaScriptNinja А кто сказал, что если вы пишите на ts, то вам не нужно писать тесты? Одно другое не исключает. Тем более, нужно уточнить, какие именно тесты. Ts заберет немного больше времени на начальных этапах. Но по мере того как растет апа сложность новых изменений будет рости скорее линейно, чем экспотенциально.
@@АмаякАбрамян-ю9э ну вот я утверждаю, что если инвестировать время потраченное на тс в тесты - надёжность будет выше
Готов на любой ваш эксперимент для проверки этого утверждения, сам несколько раз это проверял :)
Потому что тс слишком ненадежен
@@JavaScriptNinja У тестов немного другая суть. Они не падают в процессе разработки. Давайте на примерах, ситуация. У вас есть объект который приходит с бека. Объект этот используется по всей апе, в 10-х мест. Потом в ходе разработки этот рексест меняется, к примеру переименовывается поле. В случае с тестами вам нужно покрыть все кейсы. Потом вам нужно их запустить. Когда тесты упали найти все места, понять почему они упали, исправить. Это при условии что вы покрыли все кейсы. В ts изменение объекта и нахождение всех ошибок займет не более минуты. Кстати, интеграционные тесты на больших проектах, так же как и e2e могут крутится часами.
Я могу привести десятки случаев когда тесты не заменят типизации.
@@АмаякАбрамян-ю9э я работаю в гитлаб, у нас полный пайплайн занимает 5 часов при высоком уровне параллелизма.
Прекрасный пример с реквестом
Бэк изменил формат, вы не обновили typescript definition
Наши тесты такое поймают (юниты), тс нет
И да, юниты для этого и делают быстрыми чтобы гонять их во время разработки
th-cam.com/video/_esgbWGiP3c/w-d-xo.html - о каком курсе речь? (про TS) . Есть ли ссылка?
JavaScript инженер на JavaScript.ninja
Когда столкнулся с typescript орнул, оказывается все те типы которые ты пишешь в тайпскрипте вырезаются из скомпиленого JS'a, лол какой смысл их тогда вообще писать ))
смысл в том, что js код нужен браузеру, а разработчик, если у него есть ts, будет обязан правильно проставлять типы, если он этого не сделает, его код просто не скомпилится
@@yonebayashi_ как это спасет твою ситуацию если тебе из БД, или еще откуда либо придет в аргументы твоей функции вместо int 123, строка "123" и предположим ты делаешь арифметическую операцию? В итоге у тебя либо аномальное поведение при котором ты получишь искаженный результат, либо тебе нужно предварительно приводить к определенному типу данных, тогда каким образом твой ts влияет на ситуацию? Ты не получаешь в реальных тестах typerror который укажет тебе на твой косяк и ты можешь даже не знать о таком аномальном поведении твоего скрипта довольно таки долго, если ваш QA не увидит какого-то странного результата. :) Как по мне TS это костыль который придумали над JS чтобы повысить ему цену, а по факту надутый мыльный пузырь.
@@PoulFly Это уже проблема бэка, а не фронта
@@yonebayashi_ проблема типизации, неважно откуда данные приходят, саму идею тебе передал
Вот что это было такое? :) th-cam.com/video/JGu9v1riBu8/w-d-xo.html
Я не противник статической типизации. Но то как она реализована в ТС даёт больше рисков чем пользы
Ну вот мы и разошлись как в море корабли. И если computed я заменил на геттеры, а нужные свойства обернул в BahaviorSubject и подписался на изменения, то с отслеживанием изменений геттеров сложнее. Я конечно могу создать Subject, и в геттере явно вызывать subject.next(newValue), но выглядит как-то не очень. В общем пока сделал методом,
getPaginatedTickers, и просто добавил проверку this.startIndex >= filteredTickers.length для изменения страницы. Надо бы почитать, как там в ангуляре принято делать, и потом уже продолжать.
Спасибо!