Комментарии 11
135 просмотров и 27 "плюсиков"
Сразу видно - хорошая статья
Обертку над axios нужно типизировать тоже.
this.instance.get<MyResponseType>(resource, { params })
В респонсе объект data будет типизирован.
Интерфейс axios декларирован на ts. Всегда можно когда-то потом написать обертку и сделать find-replace.
Но. Это маленькая либа. Её легко обернуть. А что с другими? ui-kit тоже оборачивать прокси-компонентами? А сверху еще одна обертка кастомизацией? Но чтобы пройти vue-tsc - нужно будет заморочиться.
—
Общие ошибки в ответе 200, если такие есть, тоже лучше обрабатывать здесь же: и выкидывать кастомные Errors.
—
И зачем тянуть axios или обертку над ней в компоненты? Кмк, следует описывать вызовы api отдельно, типизируя их контрактами с бэка (openapi и всё такое). upd: в первой статье вы об этом и пишите.
P.S.: не претендую на истину, могу быть в чем-то не прав, тапками не кидать.
ui тоже можно обернуть, если проект большой, и разработку ведут разные люди. таким образом общий стиль приложения более однородный. ну и в базовых компонентах, так-же можно прописать кастомные пропсы, нужные в конкретном приложении.
Я специально разделил прокси-интерфейс и кастомизацию.
Причем для своего ui-kit развернуть дублирующую документацию: разработчики ходят на quasar/ant.design/materialui/etc за примерами. Ведь это не просто прокся: вы предлагаете поменять стиль.
Кастомизация - это отдельная история. Вот здесь я согласен: она нужна. Но она должна просто определять дефолтные пропсы и стилизацию.
А расширение базовых компонентов - это уже новые компоненты :)
Оборачивать ui компоненты это работа ради работы, оставьте это любителям реакта.
Завтра выйдет новая модная либа компонентов для vue 4 и вы всё равно всё это выкинете не глядя.
Просто пишите бизнес-логику максимально независимо от представления и от самого vue.
export default $Http;
Убейтесь об стену со своим export default, автоимпорты будут работать нигде.
get = async (resource, params) => this.instance.get(resource, { params });
Тут async по приколу написан?
5. Валидировать пропсы, использовать типы
Ну хорошо хоть где-то типы есть, еще бы export default выпилить
Есть множество методологий написания CSS, например БЭМ, OOCSS, SMACSS, Atomic CSS и т. п.
Я вот вообще не понимаю, как БЭМ созданных для того что бы стили не ломались при копи-пасте разметки и отсутствию тулзов, применим к Vue и Angular где есть изоляция стилей и директивы. Опишите, что именно считается блоком, а что элементом? И как сюда присунуть модификаторы и эффективно управлять ими из кода?
P.S. Скудное количество материала, еще хуже чем предыдущая часть. Не пишите такой мусор.
Стили компонента всегда изолируются при помощи директивы scoped. Это гарантирует, что любой стиль CSS
Не гарантирует https://codesandbox.io/s/mystifying-wiles-o59j9?file=/src/main.js
не создаст конфликта стилей за его пределами.
Тут конечно вопрос трактовки. Но если пределы понимать как внешние элементы, то гарантирует. А так, если задать стили для текста (цвет, размер, межстрочное расстояние и прочее), то конечно же эти значения перейдут в потомков, если в потомках не определить свои стили. И единственный вариант не менять вообще ничего - использовать Shadow DOM.
Добрый день, разрабатываю на Vue около пяти лет. Scoped в каких-то случаях работает, как здесь и описано, но точно не гарантирует отсутствие конфликтов в проекте, зато исправлять потом половину проекта от повторений - запомнится надолго.
Валидацию через магические переменные (s) тоже лучше не использовать
Я бы не разделял типизацию от объявления переменной с defineProps или defineEmits:<script setup lang="ts">
const { title, list } = defineProps<{ title: string list: Array<IItem> }>()
</script>
Что бы всё было перед глазами 😊
6 простых принципов написания приложения на Vue, которое легко поддерживать (часть 2)