#8 Бизнес логика или детали реализации? - Vue.js: концепции
Vložit
- čas přidán 7. 09. 2024
- Telegram группа: t.me/vuejs_club
Задание для подготовки в закреплённом комментарии!
---
Видео создано благодаря подписчикам проекта на нашем Patreon.
Хотите получать контент на 3 месяца раньше остальных? Присоединяйтесь! / javascriptninja
Итак, готовимся к первым практикам!
Пусть вас не пугает, что ссылки на Vue.js 2. Вы от этого не пострадаете - мы будем акцентировать внимание на всех различиях:
Вам необходимо прочитать и осознать:
- раздел "Введение" документации Vue.js 2 ru.vuejs.org/v2/guide/index.html
- раздел "Создание проекта" документации Vue-cli. cli.vuejs.org/ru/guide/creating-a-project.html#vue-create
Вы должны уметь создавать с помощью vue-cli новый проект и запускать его.
Знаем умеем. Ждём с нетерпением.
Google translate(built in) to help.
плагины и пресеты настроек по ссылке на cli тоже учить ?
Pro tip : you can watch movies at Flixzone. I've been using it for watching lots of of movies during the lockdown.
я учился на react, а пришел на проект, где с vue2. Смотрю твой канал, надеюсь будет полезно для меня.
Уточка знает как ты писал прошлым летом! Уточка придёт за тобой! 🦆
Ну не надо, ну пожажда.😭
Если честно, то у меня из за этой гребенной пропаганды везде Точка У мерещиться. Потом просмотрев видео понял, что никакого плохого контекста здесь нет. Пора заканчивать с зомбоящиком, то буду зомбоящером
Первый раз с таким форматом изложения материала встречаюсь. Спасибо, прям интересно, жду как сериал. Пошел читать документацию.
Зачастую бывает так, что суровый бэкендер просто не успевает вам дать API в те сроки, в которые вам бы хотелось. И что делать? Ждать его? Тратить время? Нет. И вот вам нужно будет комментировать все ваши аксиосы и фетчи в компонентах, заменять их на какие-то заглушки, т.е. редактировать множество файлов.
А если написать ту самую прокладку между компонентами и API, о которой говорится в видео, то такую заглушку нужно будет сделать только в одном файле, а именно в файле прокладки. И прокладка отдаст вашим компонентам те данные, которые им нужны. Вы подготовите компоненты заранее, бэкендер сообщит, что он уже готов, и вам нужно будет сделать изменения только в одном файле прокладки. А в компонентах не придётся менять ни одной строчки. Все тесты будут работать как и работали. Сплошная экономия времени и нервов
Отличный пример привели, спасибо.
Согласна, именно так я себе это и представляю
для этого и существует фулл стак, и не какие тайп скрипты в целом не нужны)ты имеешь четкое представление что ты запрашиваешь и что получаешь
@@violentiner Для мелких поделок в виде чудо-сайтиков фуллстэк ещё подойдёт, но на проекте, над которым работает несколько людей - это идиотизм
Это революционный метод онлайн преподавания, где фраза "Мы изучим" вместо "Вы изучите" меняет восприятие в корне. Кайфую.
кайфанете еще больше, когда вспомните что вью это не реакт xD
@@maxchernyshov8405 кайфую каждый раз, когда заканчиваю проект на реакте и возвращаюсь к вью.
Типичное виражение для человека которий писал и преподовал в ВУЗе
@@nickmet12 не преподавал никогда
@@nickmet12 согласен, в школах и вузах это часто употребляемое выражение... да и на ютубе каждый второй так выражается...
Это лучшее обьяснение "S", что я слышал! До этого понимал проблему скорее интуитивно. Спасибо!
Обязательно поддержку как патрона, за такой труд. Благодаря вам сэкономил 60к на курсах Владилена, а сэкономил - значит заработал.
Вот здесь красиво, кратко и доходчиво! Единственное что нужно добавить - такое разделение упрощает тестирование
Оно все упрощает, и когда спустя месяц резко задание приходит «поменяй», не пытаешься дня три понять что ты там такого наделал (когда все в кучу)но грешен, заклеван уточкой 😂
Спасибо за объяснение. Теперь я понял зачем из компонентов выносят реализацию бизнес-логики в отдельный модуль. Сколько раз это видел в различных обучающих видео, но мало кто объяснял почему он это делает.
Эти горе-учителя сами не знают почему они так делают
Спасибо за понятное объяснение Single Responsibility! Ценно.
Хоть я не учу пока vue, но очень ценю блоки концепций. Для меня, как для начинающего, такие темы, глобальные, на вес золота. Все везде конкретные технологии и примеры, а у Ильи философия и акцент на понимании. Очень интересно и полезно. Спасибо! 🤝
Очень хорошее и четкое изложение материала. Вы и Тимофей Хирьянов лучшие преподаватели. Спасибо!
Привет. Посмотрел 8-ое видео по вью. Прочитал введение по вью 2. Вопросов стало еще больше 😆 Еще раз хотел бы поблагодарить всех причастных к созданию курса. Попробвал примеры из введения в связке с vue-сlie 4 и шаблоном для vue 2. Наступил на ряд граблей. Желаю всем нам удачи в этом увлекательном приключении!
Очень хорошо обьясняете, раньше равнялся на Минина, теперь Вы мой фаворит)
Про уточку доходчиво было, спасибо! :)
Смеренно жду новые материалы. Вперёд Илья. ))) Жена смотрит на монитор , а там стрим Ильи как раз идёт и спрашивает, очередной : у тебя новый друг , чего на ужин не зовёшь ?:D
Вопросы в голове ещё не созрели . Теория впитывается хорошо. Скоро тучи сложности начнут сгущаться))
Спасибо за Ваш труд
8 урок пройден! Спасибо за ваши видео! Иду читать документацию!
Спасибо за курс. Формат очень удобный и доходчивый.
4:06 мой ответ, когда сильно заволновался на собеседовании 😂
Ещё одна серия любимого аниме!
Man, ty so much for your work! Looking forward for next lessons...
Это наверно более понятная тема нежели предыдущая) спасибо!
Спасибо, Ваш курс очень помогает.
Спасибо за урок и доступное объяснение!) Пора приобретать уточку)))
Спасибо, про утку действительно понятно
За утку отдельный лайк)
Спасибо меня тоже интересовал этот вопрос!
напоминает паттерн компонент-контейнер, где компонент для отображения в'юхи, а контейнер для получения даних, которие потом передают в компонент
Спасибо! Это просто комметарий для продвижения видео ^_^
Спасибо за информацию. Будет ли отдельное видео для настройки окружения (VS Code) для Vue?
Ахаххаха глаза кровью наливаютс)) Лайк за крутое объяснение 👍
Самая большая боль это где отлавливать ошибки и в как их отдавать дальше. И не только на js
Почитал комментарии, не я один такой тупой😂 вот сам принцип SOLID имеет немного разное значение в плане реализации на бэке и на фронте (имею ввиду бэк - не js)... с бэком я разобрался, вроде как хорошо, кроме буквы L, но на фронте это не работает, тут своя атмосфера, как здесь провести инверсию зависимостей? Это компоненты внедряемые в шаблон или что это? Как наследоваться от компонента для его расширения, чтобы не нарушить принцип открыточти и закрытости? Типа создать новый компонент импортировав в него уже существующий компонент, накатить поверх новую локигу и прокинуть нужные данные в исходный компонент? Вот не могу сообразить, надеюсь по ходу курса все станет понятнее)))
Да, да. Вот тоже очень интересно оособенно об O, L, D послушать :)
Вроде бы принцип S не совсем об ответственности файликов, компонентов или классов. Оригинальная статья говорит об ответственности за именения, которые могут потребовать те или иные акторы. С интересом послушаю как вы опишите остальные принципы, может мое понимание не совсем верно)
У нас на эту тему дискуссия в канале была. Обратите внимание на формулировку в видео - мы слегка коснулись S. Я не давал определения, S в полной версии определения - совсем про другое и гораздо ближе к тому что вы сказали
7:06 S в SOLID прицип единичной (одной) ответственности. Часто оговариваются в пользу "единой". Как и в DI часто путают inverse и inject )
Илья, поправьте если неправ. В моей картине мира S это не о том что какие-то знания в одном файле, а о том что эти знания сильно связаны в рамках какой то атомарной сущности (клас, функция, vue-компонет и т.д.). Из видео получается, если я оберну запрос в функцию и вынесу в отдельный файл, то я молодец и проблему решил, но по факту осталась та же ситуация. Что думаете?
Большое спасибо !
Уточка, когда слышит "и": OMAE WA MOI SHINDERIU
Спасибо за видео и за курс очень круто) Вопрос, нужно ли отделять бизнес логику от компонента? (имеется в виду в отдельные модули). Таки вещи как расчет себестоимости, расчет суммы, или еще какие ни будь задачи, связанные с бизнес логикой? А в самом компоненте вызывать методы (функции), типа getSum, calcPrice и т.д.
если по хорошему, то бизнес-логика и фреймворк должны находиться в разных слоях. Причём бизнес-логика ничего не должна знать про фреймворк. Фреймворки с годами сменяют друг друга, либо сильно меняются их версии, а бизнес логика остаётся) И потом функции бизнес-логики могут использоваться в разных компонентах, так что логично их вынести в другой слой
Илья - Профи!!!
спасибо за видео!
Получился Ангуляр
(и славно)
Пошел за глазными каплями для уточки
Стало понятнее 👍🏻
А есть такое же простое объяснение остальных букв из SOLID?
GRASP и SOLID будут детально объясняться в курсе
Присоединился, интересно о Солид
@@JavaScriptNinja Что за курс?
@@amirych ....ЭТОТ? (внезапно)
"у уточки глаза кровью наливаются" - порвало, запомню принцип единой ответственности :)
огонь спасибо за контент=))
Супер
Забавно слышать про отделение БЛ от реализации в языке, где нет интерфейсов.
Кроме этого, интересно узнать, что делать с БЛ, которая находится в условиях SQL запросов?
Нахожусь в предвкушении жарких роликов на тему натягивания SOLID на JS. Здесь же каждая буква стреляет))
Уточка топ)
Утка просто топ DD
Хахахаха, метод уточни просто огонь !!!!
да ептель) что-нибудь надо записывать или нет в таком формате уроков? судя по тому, что из прошлых я ничего не запомнил, то нужно
Попробуй сделать как я. Просмотрел один раз. Потом второй раз, но с паузой на непонятных моментах, отдельно нагуглить, углубление в понимание термина в общем проделать, а в конце закрепить ещё одним просмотром. Удивительно, но в большинстве случаев хорошо откладывается в мозгах
Стартую))
А у меня остался вопрос на примере axios. Мы для грамотного получения данных делаем let data = await api.getSomthing(); А уже внутри функции getSomething() дергаем axios, или надо как то по другому изолировать получение данных?
Да, именно так. В компоненте только просим данные
А мне вот всё же непонятно, зачем нужны все эти извращения с webpack, созданием бандлов, если можно просто подключить фреймворк статически в файл index.html, и писать всю логику в отдельном js-файле? Да, возможно для больших проектов это не катит, но я сужу по небольшим, где кастомная логика на JS обычно не больше 20-30 кб занимает.
А зачем тогда отдельный js файл? Надо пряв в хтмл тегом включать!
Если конкретно на примере, vuemasters сделали, отдельный файл js и в нем импортировали библиотеку axios и создали инстанс объекта axios.create. Далее в этом же файле создали функцию, которая вызывает данный инстанс и эту функцию уже экспортируем для использования где нам нужно. Это верный подход, solid?
Мне кажется, это часть этого подхода, но хорошо бы иметь еще какой-то промежуточный модуль, который вызывает методы, может быть как-то обрабатывает пришедшие данные, и уже нужный вариант отдает в компонент Vue. Например, таким промежуточным слоем могут быть vuex: мы дергаем данные через actions, сохраняем их через mutations, а в компоненте уже getters отдаем нам непосредственно сами данные.
спасибо!
онь=)) спасибо за видос
Vue JS / бесплатный курс
---
только я ссылки не вижу? или уже потерли?
спасибо / глаз замылился... почему то решил, что они должны быть в описании))
Закрепленный комментарий не видите? :)
Немного не понял почему вынесение запросов в отдельный модуль порадует уточку. Ведь наш компонент все еще будет запрашивать данные(хоть и не напрямую, но все же будет) И отображать их.
вызов абстракного метода getMyPost это не одно и то же с axios.get('/my-posts')
Да - компоненты вызывает getMyPost, но ему все равно как это работает внутри.
Возможно будет более понятно, если Ваш компонент возьму я. Вы меня не знаете. Я участвую в совершенно другом проекте. Вы не знаете логику моего проекта. Вы не знаете откуда и как конкретно я забираю данные. Обычно я не смог бы этого сделать. Если я смогу это сделать, значит архитектура более-менее. Одно дело поправить конфиг или в худшем случае файлы сервиса\контроллера e.t.c, другое поправить компонент целиком, что по сути означает написать его самому.
4:08 Призвали мурлока
Если это не будет отягощать уточку, то можно ссылки и на англ. доку vue-3?
Мне кажется написать одно слово vue3 в адресной строке, гораздо быстрее, чем писать комент на ютубе
Окей, Гугл. Игрушка уточка. Купить.
В Nuxt есть опция fetch и asyncData для компонента страницы. Эти опции не нарушают принцып single responsibility?
так вы там можете дернуть api или диспатч vuex
@@smith-dev но там можно вызвать fetch или axios на прямую. В примерах так и показано. Принцип SR не нарушается?
Пошли с уточкой читать доку. Спасибо )
4:07 НИВОЗМОЖНЯЯЯ ОРУ
Я правильно понял, это типа как в MVC разделение идёт? Для каждого компонента нужно делать отдельный файл, который отвечает за обмен данными?!
MVC это о разделении логики в целом, да.
MVVM
Теоретически, это, конечно, верно. Но, как и во всех курсах, что я видел, говорится "как правильно", но ничего не говорится о том "почему это правильно".
"Нужно разделять бизнес-логику и её реализацию". А зачем? Нет ответа.
Я пишу среднего размера сайт. Есть ТЗ, есть конкретный срок окончания. После того, как сайт будет готов, возможны какие-либо небольшие правки, но не более того. Вероятность того, что он будет модернизироваться или расширяться, стремится к нулю.
Насколько актуально для меня тратить время на то, чтобы делать всё через инъекции, чтобы потом можно было всё переделать или масштабировать?
Насколько я понимаю, есть несколько причин, чтобы разделять бизнес-логику и реализацию:
1) упростить каждый конкретный компонент (в ущерб усложнению архитектуры, стоит заметить);
2) добавить возможность заменить внедряемую реализацию на другую;
3) тестирование.
Мой проект, во-первых, имхо, недостаточно сложный, чтобы запариваться с абстрагированием получения данных от их отображения. Во-вторых, менять тот же самый axios, например, на что-то другое точно не придется. В-третьих, тестов, malheureusement, не предвидится. Так стоит ли мне тратить время на это или нет?
Понятно, что такие нюансы обсуждать с новичками затратно. У учителя математики в школе тоже нет времени объяснять ученику, зачем нужны косинусы и синусы, проще заставить заучить.
В итоге все делают что-то, просто чтобы делать что-то. Пример: иммутабельность в React-Redux. 99%-ам пользователей она нафиг не сдалась. Но так правильно, так давайте писать вместо одной строки пять, чтобы было по канону.
В конце небольшой философский вопрос) Кто хороший разработчик: кто пишет всегда хороший, универсальный и доступный код или тот, кто пытается максимально эффективно потратить человекочасы и, соответственно, деньги клиента?
Просто вынести отдельно файлик с апи запросамм не займет больше времени чем обычно, но зато когда тебе прийдётся вдруг один апи запрос поменять с /get/shop на /get_shop
Тебе не прийдётся бегать по всему проекту изменять эту строку, а просто зайти в один файлик со всеми апишками и поменять там
По последнему вопросу нужно всегда держать золотую середину) не писать слишком плохо и не упарываться в идеальный код)
Ответ очень простой. Если какая-то практика не ухудшает время на разработку (а разделение чего-то на два файла не ухудшает время на разработку) или ухудшает незначительно (условные 20%) - мы применяем ее безусловно
Разделение бизнес-логики и транспорта -как раз такая практика. Более того (мы еще увидим это) в отдельных сценариях она ускоряет разработку. Почему? Потому что мы можем проверить что слой api работает так как нам надо до начала написания компонентов
"Вероятность того, что он будет модернизироваться или расширяться, стремится к нулю". Ты этого не знаешь. Меня учили не угадывать вероятность, а создавать гибкие системы и думать о других разработчиках. С обратным я сталкиваюсь часто, когда заложенная кем-то архитектура год-два назад не позволяет быстро реализовать новую фичу и приходиться думать куда и какой костыль вставить. А думать больно.
Почему же не использовать axios я не понял и что же использовать.
Смотрите дальше :)
но как же так, отображение (Vue) - это не бизнес логика. А если вам тот же домен нужно будет перенести с вэба в мобилу?
Да, не бизнес-логика, а представление c логикой этого представления в первую очередь. Бизнес-логика работает с моделью и бизнес-правилами. И то, что назвали "реализация" в этом ролике это инфраструктура.
Поехали, из ждуниоров в мидлы!
Даа , как раз пришёл спрашивать о вынесении безнес логики, когда один компонент заполнился axios'ами и всеми возможными отображениями.. Так противно смотреть в такой код, трудно держать всё в голове )
Разделяй и влавствуй!
клиентский код это и есть бизнес логика?
Тема сисек не раскрыта. В смысле, сервисов.
Вот разве не стоит сделать как в Angular отдельный слой между компонентом и слоем получения (отправки) данных, где поместить логику приложения (не отображения)?
А видео не про слой сервисов вовсе :) Моя задача дать доступные (даже не абсолютно верные определения). А к слою сервисов мы еще вернемся и в том числе к вечному вопросу "где размещать логику приложения"
Всё что-ли ?
Почитайте вкладку "сообщество" канала. Отвлекли, продолжаем :)