После обновления Vue3 больше всего раздражает новый синтаксис Compostion API, сложность не в синтаксисе, а в новом способе организации кода.
Когда я только что перешел с Vue2 на Vue3, код строго следовал методу написания Compostion API, но я обнаружил, что он менее удобен в сопровождении, чем метод написания Option API.
вытоптанная яма
1. Разделите коды по типу технологии
При ежедневной разработке внешний интерфейс обычно запускает макет после получения интерактивного проекта или проекта дизайна, а затем пишет логический код. В Vue2 обычной практикой является размещение данных ответа вdata, логический метод помещается вmethods, что очень удобно и упрощает нам организацию нашего кода.
При использовании Compostion API vue3, если код все же будет организован в виде Vue2, это не только не улучшит качество кода, ноиз-за отсутствия ограниченийи уменьшить читабельность.
Я только что нашел кусок кода на github, как вы думаете, этот код проще, чем Vue2?
export default {
setup () {
const state = reactive({
message: '',
msgList: []
})
const router = useRouter()
let username = ''
onMounted(() => {
username = localStorage.getItem('username')
if (!username) {
router.push('/login')
return
}
})
const onSendMessage = () => {
const { message } = state
if (!message.trim().length) return
state.msgList.push({
id: new Date().getTime(),
user: username,
dateTime: new Date().getTime(),
message: state.message
})
state.message = ''
}
return {
...toRefs(state),
onSendMessage
}
}
}
На самом деле, мы уделяем слишком много внимания изменениям на грамматическом уровне и игнорируем официальную документацию, в которой упоминается слово под названием:逻辑关注点！！！！！！,
逻辑关注点是指表达同一个业务的代码内聚到一起，这也是单一职责的指导思想，我们内聚的不应该技术类型，而是业务逻辑，因为触发代码变更的往往是业务需求，因此把相同变更理由的代码放在一起，这才不会导致散弹式修改。
2. Слишком много внимания уделяется повторному использованию логики
Одной из особенностей API композиции является улучшение повторного использования логики, что не является неправильным, но в то время у меня было неправильное представление о том, что в хуки следует инкапсулировать только повторно используемую логику.
Вернемся к официальному примеру Vue.Вы обнаружите, что он разбивает логику, изначально помещенную в файл vue, наcomposablesКаталог, файл определяется в каталоге с указанием различных逻辑关注点.
Официальный адрес документа | Репозиторий справочного кода
Код в этой папке выделен и不是逻辑复用, но逻辑关注点Разделение также является основной проблемой, которую должен решить составной API, поскольку поддерживается 60% жизненного цикла приложения, а ремонтопригодность отражается в том, соответствует ли код принципу единой ответственности. код в одном месте.
Поэтому вам не следует слишком беспокоиться о необходимости повторного использования кода. Применение соответствующей избыточности повысит удобство сопровождения приложения. В книге «Путь чистой архитектуры» упоминается:Для большинства приложений ремонтопригодность важнее возможности повторного использования.
Если ваш код действительно многоразовый, его можно переместить во внешний каталог проекта и упаковать в отдельный файл-ловушку.
Вид на тебя Юси
Когда предлагался compostion API, было много людей с разными мнениями, были возражения и поддержка, по сути ничего плохого не было, просто люди столкнулись с разными сценариями, которые привели к разным мнениям. Прочитав RFC API композиции, я нашел ответы автора на некоторые вопросы, а также разобрался с некоторыми ключевыми вопросами.Содержимое переведено не полностью.Полное содержание рекомендуется просматривать в исходном тексте.исходный адрес
Проблема первая: compostion api вообще ничего не решает, он просто гоняется за новыми вещами
Ю Юси:Не согласен с этим мнением. Сначала Vue был небольшим, но сейчас он широко используется в бизнес-сферах разного уровня сложности, с чем-то можно легко справиться на основе option API, а с чем-то нет. Например следующий сценарий:
- Большие компоненты (сотни строк) с большим количеством логики
- Логика многократного использования в нескольких компонентах
Для вопроса 1 вам нужно разделить каждую логику на разные варианты, например, части логики нужны некоторые данные ответа, вычисляемое свойство, некоторые свойства и методы прослушивания. Когда вы понимаете эту логику, вам нужно продолжать двигаться вверх и вниз, чтобы прочитать.Хотя вы знаете, к какому типу относятся некоторые свойства, вы не знаете их конкретных функций. Ситуация еще хуже, когда компонент содержит несколько логик.
С новым API вы можете комбинировать данные и логику, и самое главное, вы можете干净的把这些逻辑提取到一个函数，甚至一个单独的文件中。
Проблема 2: Использование нового API приводит к тому, что логика разбрасывается по разным местам, что нарушает «разделение задач»
Ю Юси:Эта проблема аналогична организации файлов проекта. Многие из нас согласны с тем, что организация по типу файла (HTML для макета, CSS для стилей, JS для логики) — неправильный путь, потому что принудительное разделение связанного кода на три файла просто создает иллюзию «разделения задач». . Ключевым моментом здесь является то, что «проблемы» не определяются типами файлов. Вместо этого большинство из нас предпочитает功能或者职责упорядочивать файлы,这正是人们喜欢Vue单文件组件的原因. SFC — это способ организации кода по функциям, но по иронии судьбы, когда SFC впервые была представлена, многие отвергли ее как нарушение разделения задач.
Проблема 3: Новый синтаксис заставляет Vue терять свою простоту, что приводит к появлению «спагетти-кода» и снижает удобство сопровождения проекта.
Ю Юси:Наоборот, новый API призван улучшить долгосрочную ремонтопригодность проекта.
Если мы посмотрим на любой проект javascript, мы начнем с файла входа, который по сути является «основной» функцией, которая неявно вызывается при запуске вашего приложения. Если есть только одна запись функции, это приведет к спагетти-коду, тогда все js-проекты являются спагетти-кодом. По-видимому, нет, потому что разработчики организуют свой код с помощью модульности кода или более мелких функций.
Также я согласен с тем, что новый API теоретически понизит минимальную планку качества кода. Но мы можем смягчить это, используя те же методы, которые мы использовали для предотвращения превращения кода в спагетти. С другой стороны, новый API может поднять верхний предел качества кода, и вы можете выполнить рефакторинг для более качественного кода, чем API-интерфейс option. Кроме того, на основе Option API вам приходится решать такие проблемы, как примеси.
Многие люди думают, что «Vue теряет простоту», но на самом деле он просто теряет возможность проверки типов кода в компонентах (то есть вы не знаете, является ли переменная данными, методом или вычисляемой). Но с новым API реализация проверки типов также очень проста для реализации предыдущих функций. То есть вы не должны ограничиваться параметром API и больше ориентироваться на логическую связность.
Суммировать
Вышеприведенное является лишь выдержкой из нескольких небольших вопросов, обсуждаемых в RFC. Если у вас есть другие вопросы о новом API, рекомендуется перейти на github, чтобы прочитать исходный текст. В исходном тексте обсуждается множество вопросов, поэтому я не буду суммировать их по одному.
Но из содержания обсуждения и моего реального опыта с новым API мы должны обратить внимание на изменение мышления организации кода, запомните слово."逻辑关注点".
Прием на работу
Компания: Guangzhou Zhijing Technology Co., Ltd.
Местонахождение: Гуанчжоу Хайчжу Чжихуэй
Ключевые слова: единорог, раунд D+, оценка в 20 миллиардов.
Стек технологий: Vue3, Typescript, Taro
Заинтересованы в отправке резюме по адресу:zhengguorong@zj.tech