Итак, готовимся к первым практикам! Пусть вас не пугает, что ссылки на 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 новый проект и запускать его.
Если честно, то у меня из за этой гребенной пропаганды везде Точка У мерещиться. Потом просмотрев видео понял, что никакого плохого контекста здесь нет. Пора заканчивать с зомбоящиком, то буду зомбоящером
Хоть я не учу пока vue, но очень ценю блоки концепций. Для меня, как для начинающего, такие темы, глобальные, на вес золота. Все везде конкретные технологии и примеры, а у Ильи философия и акцент на понимании. Очень интересно и полезно. Спасибо! 🤝
Зачастую бывает так, что суровый бэкендер просто не успевает вам дать API в те сроки, в которые вам бы хотелось. И что делать? Ждать его? Тратить время? Нет. И вот вам нужно будет комментировать все ваши аксиосы и фетчи в компонентах, заменять их на какие-то заглушки, т.е. редактировать множество файлов. А если написать ту самую прокладку между компонентами и API, о которой говорится в видео, то такую заглушку нужно будет сделать только в одном файле, а именно в файле прокладки. И прокладка отдаст вашим компонентам те данные, которые им нужны. Вы подготовите компоненты заранее, бэкендер сообщит, что он уже готов, и вам нужно будет сделать изменения только в одном файле прокладки. А в компонентах не придётся менять ни одной строчки. Все тесты будут работать как и работали. Сплошная экономия времени и нервов
Спасибо за объяснение. Теперь я понял зачем из компонентов выносят реализацию бизнес-логики в отдельный модуль. Сколько раз это видел в различных обучающих видео, но мало кто объяснял почему он это делает.
Оно все упрощает, и когда спустя месяц резко задание приходит «поменяй», не пытаешься дня три понять что ты там такого наделал (когда все в кучу)но грешен, заклеван уточкой 😂
Привет. Посмотрел 8-ое видео по вью. Прочитал введение по вью 2. Вопросов стало еще больше 😆 Еще раз хотел бы поблагодарить всех причастных к созданию курса. Попробвал примеры из введения в связке с vue-сlie 4 и шаблоном для vue 2. Наступил на ряд граблей. Желаю всем нам удачи в этом увлекательном приключении!
Смеренно жду новые материалы. Вперёд Илья. ))) Жена смотрит на монитор , а там стрим Ильи как раз идёт и спрашивает, очередной : у тебя новый друг , чего на ужин не зовёшь ?:D Вопросы в голове ещё не созрели . Теория впитывается хорошо. Скоро тучи сложности начнут сгущаться))
Илья, поправьте если неправ. В моей картине мира S это не о том что какие-то знания в одном файле, а о том что эти знания сильно связаны в рамках какой то атомарной сущности (клас, функция, vue-компонет и т.д.). Из видео получается, если я оберну запрос в функцию и вынесу в отдельный файл, то я молодец и проблему решил, но по факту осталась та же ситуация. Что думаете?
Почитал комментарии, не я один такой тупой😂 вот сам принцип SOLID имеет немного разное значение в плане реализации на бэке и на фронте (имею ввиду бэк - не js)... с бэком я разобрался, вроде как хорошо, кроме буквы L, но на фронте это не работает, тут своя атмосфера, как здесь провести инверсию зависимостей? Это компоненты внедряемые в шаблон или что это? Как наследоваться от компонента для его расширения, чтобы не нарушить принцип открыточти и закрытости? Типа создать новый компонент импортировав в него уже существующий компонент, накатить поверх новую локигу и прокинуть нужные данные в исходный компонент? Вот не могу сообразить, надеюсь по ходу курса все станет понятнее)))
Вроде бы принцип S не совсем об ответственности файликов, компонентов или классов. Оригинальная статья говорит об ответственности за именения, которые могут потребовать те или иные акторы. С интересом послушаю как вы опишите остальные принципы, может мое понимание не совсем верно)
У нас на эту тему дискуссия в канале была. Обратите внимание на формулировку в видео - мы слегка коснулись S. Я не давал определения, S в полной версии определения - совсем про другое и гораздо ближе к тому что вы сказали
Спасибо за видео и за курс очень круто) Вопрос, нужно ли отделять бизнес логику от компонента? (имеется в виду в отдельные модули). Таки вещи как расчет себестоимости, расчет суммы, или еще какие ни будь задачи, связанные с бизнес логикой? А в самом компоненте вызывать методы (функции), типа getSum, calcPrice и т.д.
если по хорошему, то бизнес-логика и фреймворк должны находиться в разных слоях. Причём бизнес-логика ничего не должна знать про фреймворк. Фреймворки с годами сменяют друг друга, либо сильно меняются их версии, а бизнес логика остаётся) И потом функции бизнес-логики могут использоваться в разных компонентах, так что логично их вынести в другой слой
А у меня остался вопрос на примере axios. Мы для грамотного получения данных делаем let data = await api.getSomthing(); А уже внутри функции getSomething() дергаем axios, или надо как то по другому изолировать получение данных?
Если конкретно на примере, vuemasters сделали, отдельный файл js и в нем импортировали библиотеку axios и создали инстанс объекта axios.create. Далее в этом же файле создали функцию, которая вызывает данный инстанс и эту функцию уже экспортируем для использования где нам нужно. Это верный подход, solid?
Мне кажется, это часть этого подхода, но хорошо бы иметь еще какой-то промежуточный модуль, который вызывает методы, может быть как-то обрабатывает пришедшие данные, и уже нужный вариант отдает в компонент Vue. Например, таким промежуточным слоем могут быть vuex: мы дергаем данные через actions, сохраняем их через mutations, а в компоненте уже getters отдаем нам непосредственно сами данные.
А мне вот всё же непонятно, зачем нужны все эти извращения с webpack, созданием бандлов, если можно просто подключить фреймворк статически в файл index.html, и писать всю логику в отдельном js-файле? Да, возможно для больших проектов это не катит, но я сужу по небольшим, где кастомная логика на JS обычно не больше 20-30 кб занимает.
Забавно слышать про отделение БЛ от реализации в языке, где нет интерфейсов. Кроме этого, интересно узнать, что делать с БЛ, которая находится в условиях SQL запросов? Нахожусь в предвкушении жарких роликов на тему натягивания SOLID на JS. Здесь же каждая буква стреляет))
Попробуй сделать как я. Просмотрел один раз. Потом второй раз, но с паузой на непонятных моментах, отдельно нагуглить, углубление в понимание термина в общем проделать, а в конце закрепить ещё одним просмотром. Удивительно, но в большинстве случаев хорошо откладывается в мозгах
Немного не понял почему вынесение запросов в отдельный модуль порадует уточку. Ведь наш компонент все еще будет запрашивать данные(хоть и не напрямую, но все же будет) И отображать их.
вызов абстракного метода getMyPost это не одно и то же с axios.get('/my-posts') Да - компоненты вызывает getMyPost, но ему все равно как это работает внутри.
Возможно будет более понятно, если Ваш компонент возьму я. Вы меня не знаете. Я участвую в совершенно другом проекте. Вы не знаете логику моего проекта. Вы не знаете откуда и как конкретно я забираю данные. Обычно я не смог бы этого сделать. Если я смогу это сделать, значит архитектура более-менее. Одно дело поправить конфиг или в худшем случае файлы сервиса\контроллера e.t.c, другое поправить компонент целиком, что по сути означает написать его самому.
Да, не бизнес-логика, а представление c логикой этого представления в первую очередь. Бизнес-логика работает с моделью и бизнес-правилами. И то, что назвали "реализация" в этом ролике это инфраструктура.
Даа , как раз пришёл спрашивать о вынесении безнес логики, когда один компонент заполнился axios'ами и всеми возможными отображениями.. Так противно смотреть в такой код, трудно держать всё в голове ) Разделяй и влавствуй!
Теоретически, это, конечно, верно. Но, как и во всех курсах, что я видел, говорится "как правильно", но ничего не говорится о том "почему это правильно". "Нужно разделять бизнес-логику и её реализацию". А зачем? Нет ответа. Я пишу среднего размера сайт. Есть ТЗ, есть конкретный срок окончания. После того, как сайт будет готов, возможны какие-либо небольшие правки, но не более того. Вероятность того, что он будет модернизироваться или расширяться, стремится к нулю. Насколько актуально для меня тратить время на то, чтобы делать всё через инъекции, чтобы потом можно было всё переделать или масштабировать? Насколько я понимаю, есть несколько причин, чтобы разделять бизнес-логику и реализацию: 1) упростить каждый конкретный компонент (в ущерб усложнению архитектуры, стоит заметить); 2) добавить возможность заменить внедряемую реализацию на другую; 3) тестирование. Мой проект, во-первых, имхо, недостаточно сложный, чтобы запариваться с абстрагированием получения данных от их отображения. Во-вторых, менять тот же самый axios, например, на что-то другое точно не придется. В-третьих, тестов, malheureusement, не предвидится. Так стоит ли мне тратить время на это или нет? Понятно, что такие нюансы обсуждать с новичками затратно. У учителя математики в школе тоже нет времени объяснять ученику, зачем нужны косинусы и синусы, проще заставить заучить. В итоге все делают что-то, просто чтобы делать что-то. Пример: иммутабельность в React-Redux. 99%-ам пользователей она нафиг не сдалась. Но так правильно, так давайте писать вместо одной строки пять, чтобы было по канону. В конце небольшой философский вопрос) Кто хороший разработчик: кто пишет всегда хороший, универсальный и доступный код или тот, кто пытается максимально эффективно потратить человекочасы и, соответственно, деньги клиента?
Просто вынести отдельно файлик с апи запросамм не займет больше времени чем обычно, но зато когда тебе прийдётся вдруг один апи запрос поменять с /get/shop на /get_shop Тебе не прийдётся бегать по всему проекту изменять эту строку, а просто зайти в один файлик со всеми апишками и поменять там
Ответ очень простой. Если какая-то практика не ухудшает время на разработку (а разделение чего-то на два файла не ухудшает время на разработку) или ухудшает незначительно (условные 20%) - мы применяем ее безусловно Разделение бизнес-логики и транспорта -как раз такая практика. Более того (мы еще увидим это) в отдельных сценариях она ускоряет разработку. Почему? Потому что мы можем проверить что слой api работает так как нам надо до начала написания компонентов
"Вероятность того, что он будет модернизироваться или расширяться, стремится к нулю". Ты этого не знаешь. Меня учили не угадывать вероятность, а создавать гибкие системы и думать о других разработчиках. С обратным я сталкиваюсь часто, когда заложенная кем-то архитектура год-два назад не позволяет быстро реализовать новую фичу и приходиться думать куда и какой костыль вставить. А думать больно.
Тема сисек не раскрыта. В смысле, сервисов. Вот разве не стоит сделать как в Angular отдельный слой между компонентом и слоем получения (отправки) данных, где поместить логику приложения (не отображения)?
А видео не про слой сервисов вовсе :) Моя задача дать доступные (даже не абсолютно верные определения). А к слою сервисов мы еще вернемся и в том числе к вечному вопросу "где размещать логику приложения"
