Я не говорила, что мне не нравится этот вариант, мне впринципе Vue 3 больше нравится, и там я использовала только Composition Api.
Просто тема статьи другая, я это наверное явно не обозначила, но опция Composable на некоторых проектах не стоит, так как весь проект на Options Api, и composable не совсем вписывается.
Для 3 версии Vue я потом хотела сделать решение, где как раз таки класс встраивается в компонент через composable.
Это статья-рассуждение о том, что я чаще всего видела в проектах, когда появлялась необходимость вынести логику. И рассуждение как раз и сводилось к тому, что чаще используют инструменты, не приспособленные хранить и реализовывать внутри себя логику, которая уже начинает оформляться в сервис.
В блоке вводные я как раз описала, как на мой взгляд сервис должен работать, и какие ситуации покрывать.
Про этот пакет в курсе, я использовала его на практике на проекте, где компоненты были написаны как классы. Но при изменениях в классе ломался hot-reloading, при этом ломался так, как будто у тебя ошибка какая-то происходит, что очень сильно путало. И по какой-то причине не удалось встроить в стор и роутер файлы, но уже не помню по какой, пришлось там просто синглтон получать, что свело на нет пользу пакета.
Я создала типа упрощённую версию, которая будет работать при любых вводных, так как она максимально простая.
Здесь нет конкретной задачи, есть идея о том, какие сервисы мне хочется проектировать. Вводные требования я прописала в конце статьи, эти требования покрывают большую часть узких кейсов, которыми страдают остальные решения.
Provide/inject в плане выноса логики страдает проблемой общего родителя (он обязателен) + необходимость встраивать в родителя, что засоряет код ненужными вещами собственно говоря для родителя. + еще несколько минусов, описанных в секции cons, но эти 2 самые весомые для меня.
Да, я действительно забыла указать EventBus, но он слишком неочевидный, как вы уже сами сказали, отследить вызов события и его listener - не очень удобно.
Я хотела сделать логику, при которой сервис как таковой вообще не будет связан с Vue, потому что если мы выносим логику в сервис, то фреймворк там уже не должен иметь значения. То есть я нацелилась конкретно на классы, и как можно удобно использовать их в компонентах.
Вам будет понятнее, если вы посмотрите реализацию (ссылка на репозиторий указана в конце статьи), либо дождетесь второй и третьей части, где я буду более подробно рассказывать о том, что я сделала.
На данный момент на стороне бэкенда популярен паттерн REST-api, что говорит о том, что они отдают чистые данные, связанные с конкретными сущностями. Клиент на данный момент не только рисует кнопки и добавляет реактивность, а в том числе сращивает все эти запросы между собой.
Часто данные приходят не в удобном виде, и нам приходится писать адаптеры, добавлять форматирование и так далее.
Часть логики, связанную с рендерингом, считается хорошей практикой выносить клиент.
Например, последняя моя задача: есть страница для сбора паспортных данных, она включает в себя с 10 разных экранов, которые должны показаться в разных случаях. Условно, сначала мы приходим на первый экран, при успехе попадаем на экран 2, при провале попадаем на экран 3, если у экрана 2 успех, то мы переходим на экран 4 и т.д. Где хранить эту логику? Она очень прямо связана с бизнес-логикой - это флоу клиента, но при этом она связана с отображением экранов на клиенте. Мы храним эту логику на клиенте, потому что нам проще регулировать отображение экранов, чем если бы это делали на сервере.
Я таким образом делала, в проекте линтер настраивала с возможностью писать console.log, а потом запуская линтер в CI дописывала правило через команду в терминале. Таким образом при локальной разработке ругани не было, а вот на стадии принятия MR он отваливался
Мы не сами отправляем запрос, аналитика сама это делает, мы же просто вызываем функцию (в случае фб или яндекса) или пушим в массив (аналитика добавляет dataLayer).
Теги интересные, но не все представляю как применить в практике)
По продвинутому выбору даты не указано, что в Safari не поддерживается. + выбор только конкретно месяца и дня не отменяет необходимость валидации перед отправкой, так как в любом случае теги очень легко убираются из html. Я редко пользуюсь встроенными возможностями (не только конкретно про этот пример) именно по причине того, что все равно буду также делать валидацию в js. Интересный тег, который тоже подходит в тематику валидации: pattern (покрытие 96.88% на caniuse)
По поводу тегов на форме вообще сложно представить, что это может заинтересовать, почти все формы сейчас проходят через доп. обработку данных, валидацию, отлов ошибок при запросе, что одними тегами конечно сделать сложно
По метрикам выше указывали, что гугл аналитика конечно чаще используется (также яндекс метрика, фейсбук), там подобные клики можно вообще настроить внутри системы не заходя в код (но с SPA я предпочитаю сама управлять частью особо важных событий, чтобы быть уверенной, что ререндер не повлияет на работу метрики). И выбор конкретных метрик зависит от маркетологов, а не от разработчиков, поэтому увы, но влияния у нас не так много)
Я реализовывала в практике кастомную статистику, но там одного PING конечно было недостаточно, мы туда посылали дополнительные данные в виде времени, проведенного на странице, номера сессии и всяких остальных фич, поэтому тоже получается, что применить теги было бы сложно.
Такой депрессивный комментарий, очень захотелось как-то поддержать! Если честно, я совершенно не согласна с системой обучения в наших школах, нас очень сильно ругают за ошибки, не такая грамматическая конструкция, не то произношение — и оценка снижается. ИМХО, но это ставит психологический блок на другой язык. Я лично поборола этот страх, когда начала активно общаться с носителями языка, сначала было очень сложно, а потом привыкаешь и начинаешь замечать, что им особо это не важно и они сами делают ошибки еще похлеще нас.
Спасибо про упоминание полезности какой-то части, для меня важно понимать, что конкретно было полезно! Статья изначально задумывалась не как «пинок для лентяя», а для людей которые распределили приоритеты, руководствуясь этими конкретными аргументами)
По поводу ваших вопросов, могу ответить на них отдельно, если они не в пустоту заданы, мне всегда было интересно делиться опытом!
И прошу извинить, если для вас это показалось агрессивно, скорее дело в заголовке, который мне хотелось сделать «продающим», чтобы больше людей увидели статью.
И на самом деле вы будете абсолютно правы! Я постаралась привести практические аргументы, которые будут чуть более очевидны, чем просто просмотр вакансий с непониманием, почему там вообще просят английский язык)
В практике встречались люди, которые жалели, что поздно начали учить английский, я подумала, что было бы неплохо осветить эту тему и кому-то еще в начале подсказать, что стоит все-таки уделить этому время.
Я не говорила, что мне не нравится этот вариант, мне впринципе Vue 3 больше нравится, и там я использовала только Composition Api.
Просто тема статьи другая, я это наверное явно не обозначила, но опция Composable на некоторых проектах не стоит, так как весь проект на Options Api, и composable не совсем вписывается.
Для 3 версии Vue я потом хотела сделать решение, где как раз таки класс встраивается в компонент через composable.
Статья написана про старые проекты на Vue 2, написанные на Options Api, которые не используют Composition Api. Там нет такой опции.
Это статья-рассуждение о том, что я чаще всего видела в проектах, когда появлялась необходимость вынести логику. И рассуждение как раз и сводилось к тому, что чаще используют инструменты, не приспособленные хранить и реализовывать внутри себя логику, которая уже начинает оформляться в сервис.
В блоке вводные я как раз описала, как на мой взгляд сервис должен работать, и какие ситуации покрывать.
Потому что статья про Vue 2
Напишите статью!) Очень мало способов решения именно на просторах интернета, что и подтолкнуло меня написать статью
Я не знала про этот паттерн, но это по сути то, что я и сделала для себя
Про этот пакет в курсе, я использовала его на практике на проекте, где компоненты были написаны как классы. Но при изменениях в классе ломался hot-reloading, при этом ломался так, как будто у тебя ошибка какая-то происходит, что очень сильно путало. И по какой-то причине не удалось встроить в стор и роутер файлы, но уже не помню по какой, пришлось там просто синглтон получать, что свело на нет пользу пакета.
Я создала типа упрощённую версию, которая будет работать при любых вводных, так как она максимально простая.
Здесь нет конкретной задачи, есть идея о том, какие сервисы мне хочется проектировать. Вводные требования я прописала в конце статьи, эти требования покрывают большую часть узких кейсов, которыми страдают остальные решения.
Provide/inject в плане выноса логики страдает проблемой общего родителя (он обязателен) + необходимость встраивать в родителя, что засоряет код ненужными вещами собственно говоря для родителя. + еще несколько минусов, описанных в секции cons, но эти 2 самые весомые для меня.
Да, я действительно забыла указать EventBus, но он слишком неочевидный, как вы уже сами сказали, отследить вызов события и его listener - не очень удобно.
Я хотела сделать логику, при которой сервис как таковой вообще не будет связан с Vue, потому что если мы выносим логику в сервис, то фреймворк там уже не должен иметь значения. То есть я нацелилась конкретно на классы, и как можно удобно использовать их в компонентах.
Вам будет понятнее, если вы посмотрите реализацию (ссылка на репозиторий указана в конце статьи), либо дождетесь второй и третьей части, где я буду более подробно рассказывать о том, что я сделала.
На данный момент на стороне бэкенда популярен паттерн REST-api, что говорит о том, что они отдают чистые данные, связанные с конкретными сущностями. Клиент на данный момент не только рисует кнопки и добавляет реактивность, а в том числе сращивает все эти запросы между собой.
Часто данные приходят не в удобном виде, и нам приходится писать адаптеры, добавлять форматирование и так далее.
Часть логики, связанную с рендерингом, считается хорошей практикой выносить клиент.
Например, последняя моя задача: есть страница для сбора паспортных данных, она включает в себя с 10 разных экранов, которые должны показаться в разных случаях. Условно, сначала мы приходим на первый экран, при успехе попадаем на экран 2, при провале попадаем на экран 3, если у экрана 2 успех, то мы переходим на экран 4 и т.д. Где хранить эту логику? Она очень прямо связана с бизнес-логикой - это флоу клиента, но при этом она связана с отображением экранов на клиенте. Мы храним эту логику на клиенте, потому что нам проще регулировать отображение экранов, чем если бы это делали на сервере.
Я таким образом делала, в проекте линтер настраивала с возможностью писать console.log, а потом запуская линтер в CI дописывала правило через команду в терминале. Таким образом при локальной разработке ругани не было, а вот на стадии принятия MR он отваливался
А чем это отличается от темплейтов в IDE? Ими же тоже можно обмениваться
Так там же не запрос) поэтому ping все равно не подойдёт наверное. Обычно просто можно написать onclick
Мы не сами отправляем запрос, аналитика сама это делает, мы же просто вызываем функцию (в случае фб или яндекса) или пушим в массив (аналитика добавляет dataLayer).
Теги интересные, но не все представляю как применить в практике)
pattern(покрытие 96.88% на caniuse)Я реализовывала в практике кастомную статистику, но там одного PING конечно было недостаточно, мы туда посылали дополнительные данные в виде времени, проведенного на странице, номера сессии и всяких остальных фич, поэтому тоже получается, что применить теги было бы сложно.
По поводу ваших вопросов, могу ответить на них отдельно, если они не в пустоту заданы, мне всегда было интересно делиться опытом!
И прошу извинить, если для вас это показалось агрессивно, скорее дело в заголовке, который мне хотелось сделать «продающим», чтобы больше людей увидели статью.
В практике встречались люди, которые жалели, что поздно начали учить английский, я подумала, что было бы неплохо осветить эту тему и кому-то еще в начале подсказать, что стоит все-таки уделить этому время.