Второй особенностью является Hot Module Replacement (HMR) - что позволяет приложению не занимать много пространства
HMR никак не влияет на размер. В документации написано, что HMR остается быстрым, независимо от размера приложения
Как раз и можно увидеть експорт конфигурации приложения, и в объекте есть свойство plugins - через которое мы можем подключать плагины (например vue router)
Подключение Vue router не имеет никакого отношения к плагинам в Vite
В секции про HMR вообще какой-то бред написан, непонятно как это всё связано с SFC и script setup (спойлер - никак)
Избавляемся от .vue, .ts и .html файлов и склеиваем их в один .ts файл. “Зачем это всё?” — спросите вы.
Действительно спрошу. SFC - это как раз про .vue файлы, в которых присутствуют и template и script и (опционально) style. Зачем вместо этого держать разметку компонента в строке, как в доисторические времена без сборщиков? (К тому же, так ещё и тянутся в бандл лишние килобайты компилятор шаблонов)
И отдельный вопрос - зачем backend разработчиком руками настраивать Webpack, когда есть Vue CLI (а в 2022 году - Vite)?
ну вот как раз композаблы (use-функции) это общеизвестный паттерн. Когда мы видим функцию useFoo, мы понимаем, что это композабл. Мы ожидаем, что она будет принимать/возвращать рефы и осуществлять какие-то реактивные операции. А тут у нас есть класс, о котором мы можем только догадываться, что его поля реактивно связаны с чем-то
В контексте ООП полиморфизм - это про то, как код одинаково работает с разными реализациями одного интерфейса / наследниками класса.
interface Transport {
fun moveTo(location: Location)
}
class Car: Transport {
override fun moveTo(location: Location) {
...
}
}
class Bicycle: Transport {
override fun moveTo(location: Location) {
...
}
}
fun moveToStart(transport: Transport) {
transport.moveTo(Location(0, 0))
}
В этом примере функция moveToStart работает с любыми реализациями Transport, используя полиморфизм.
А то что сейчас в примере в статье - это про параметрический полиморфизм. Да, это тоже полиморфизм, но к ООП он не имеет никакого отношения.
А откуда взялась информация о том, что Pinia 2 - для Vue 3, а Pinia 1 - для Vue 2? Вторая версия пиньи отлично работает со вторым же вью. (Я вижу, что и в оригинале так написано, но вопрос от этого не пропадает). Это написано буквально в первых же строках документации
Это ведь специфично только для Vue
Это такая форма риторического вопроса, который является утверждением
Советую попробовать, потому что
это всё-таки неправда
Потому что расчёт не на такие простейшие примеры?
HMR никак не влияет на размер. В документации написано, что HMR остается быстрым, независимо от размера приложения
Подключение Vue router не имеет никакого отношения к плагинам в Vite
В секции про HMR вообще какой-то бред написан, непонятно как это всё связано с SFC и script setup (спойлер - никак)
Ну просто это почему-то всегда не концептуальные статьи по языку или описания фич новых релизов, а описание конкретно фич Java 8
Интересно, как долго ещё будут писаться и переводиться статьи о релизе 8-летней давности?
так можно в исходном коде написать debugger, вместо того чтобы ставить точку останова в девтулзах
Действительно спрошу. SFC - это как раз про .vue файлы, в которых присутствуют и template и script и (опционально) style.
Зачем вместо этого держать разметку компонента в строке, как в доисторические времена без сборщиков? (К тому же, так ещё и тянутся в бандл лишние килобайты компилятор шаблонов)
И отдельный вопрос - зачем backend разработчиком руками настраивать Webpack, когда есть Vue CLI (а в 2022 году - Vite)?
ну вот как раз композаблы (use-функции) это общеизвестный паттерн. Когда мы видим функцию useFoo, мы понимаем, что это композабл. Мы ожидаем, что она будет принимать/возвращать рефы и осуществлять какие-то реактивные операции.
А тут у нас есть класс, о котором мы можем только догадываться, что его поля реактивно связаны с чем-то
А какая причина хранить глобальное состояние не в сторе?
А какой, собственно, профит от того, что теперь у нас это поле стало рефом (причём неявно)?
Ну, компактная то она компактная, только к ООП отношения не имеет, повторюсь
Да, я немного ошибся. Параметрический полиморфизм - это про описание кода в общем виде для любых типов аргументов (с дженериками)
А пример из статьи с перегрузками - это как раз ad-hoc полиморфизм, действительно.
В контексте ООП полиморфизм - это про то, как код одинаково работает с разными реализациями одного интерфейса / наследниками класса.
В этом примере функция moveToStart работает с любыми реализациями Transport, используя полиморфизм.
А то что сейчас в примере в статье - это про параметрический полиморфизм. Да, это тоже полиморфизм, но к ООП он не имеет никакого отношения.
Пример с перегрузками не имеет ничего общего с полиморфизмом в контексте ООП
А откуда взялась информация о том, что Pinia 2 - для Vue 3, а Pinia 1 - для Vue 2? Вторая версия пиньи отлично работает со вторым же вью. (Я вижу, что и в оригинале так написано, но вопрос от этого не пропадает).
Это написано буквально в первых же строках документации
Что бы это значило?