Комментарии 135
Добавлю. Особого преимущества от нового синтаксиса также не увидел. Да, появилась формальная возможность группировать данные, у меня такой острой необходимости не возникало, поэтому возможно я и не до конца понял суть нововведений.
Все примеры теперь могут быть написаны 4-мя различными способами, что уничтожает преимущества Vue над другими фрэймворками в плане простоты изучения и количества путаницы.
В чем вообще преимущество группировки? На мой взгляд, как раз, разделение на типы (data, methods, computed) более наглядный и структурированный способ разработки.
Этот API приносит мало пользы, но много путаницы
Статья же как раз показывает обратное, с примерами.
Все примеры теперь могут быть написаны 4-мя различными способами
Какими способами? В статье есть только два варианта: 2.х и предложенный 3.х. Откуда 4 способа берутся?
В чем вообще преимущество группировки? На мой взгляд, как раз, разделение на типы (data, methods, computed) более наглядный и структурированный способ разработки.
В статье это показано на примере организации файлов. Вы же группируете файлы по проектам, а не "тексты – отдельно, таблицы – отдельно".
Так и здесь, группировка по фичам практичнее, чем по типам данных, когда одна фича расползается по разным секциям декларации.
С моей точки зрения стало хуже, в первом примере я долго не въезжал каким образом все драматически лучше организовалось, пока не понял, что единственное что приводит к организации это комментарии // Pet name, //Pet color….
Второй пример уже проще понять, но количество кода выросло на 30%.
Опять же, я в теме не разбираюсь, но стоит ли вносить такие изменения, которые помогают с «большими» компонентами в любой, даже самый маленький компонент(а на сколько я понимаю когда-то, в дальнейшем, новый подход станет единственным)?
const petName = {
data() {
return {
petName: ""
};
},
computed: {
header() {
if (this.petName) {
return "My Pet " + this.petName;
}
return "Enter Pet Details";
}
}
};
const petColor = {
data() {
return {
petColor: "#000"
};
},
computed: {
petColorDarker() {
return tinycolor(this.petColor)
.darken()
.toString();
},
shadow() {
return "2px 2px " + this.petColorDarker;
}
}
};
const petSize = {
data() {
return {
petSize: ""
};
},
computed: {
borderStyle() {
switch (this.petSize) {
case "Small":
return "dotted";
case "Medium":
return "dashed";
default:
return "solid";
}
},
headerSize() {
switch (this.petSize) {
case "Small":
return "12px";
case "Large":
return "60px";
default:
return "30px";
}
}
}
};
export default {
components: {
ColorPicker
},
data() {
return {
...petName.data(),
...petColor.data(),
...petSize.data()
};
},
computed: {
...petName.computed,
...petColor.computed,
...petSize.computed
}
};
Vue.js действительно прекрасен простотой вхождения, однозначностью и стабильной работой.
это уже не VUE, а что-то другое просто
Верно. Это… тенденция.
Angular 1 -> Angular 2 — уже не Angular, а что-то другое.
React -> React 16.8 with Hooks — уже не React, а что-то другое.
Vue -> Vue 3 — уже не Vue, а что-то другое.
Всё верно. Это уже не те и не то! (От них если что и осталось, то только и только… название в качестве мимикрии. Не более того. Не более)
P.S.
Ах, да, мы же можем не переписывать старое! — Ну, да, через год никто не поймёт и никто не захочет вообще копаться в старом синтаксисе вообще от слова… совсем!
Или нет, в AngularJS/Angular!
Хоть убейте, но не могу понять а что плохого в AngularJS? Да он устарел, но он по прежнему позволяет быстро и просто сделать небольшое SPA, да и структура у него для новичков понятная, в общем мне кажется зря его так, да устаревший, но есть еще порох в пороховницах.
Поменяли шило на мыло. Могли же сделать нормально:
class MyComponent {
@observable petName = ""
@computed header() {
if (this.petName) return "My Pet " + this.petName
return "Enter Pet Details"
}
@observable petColor = "#000"
@computed petColorDarker() {
return tinycolor(this.petColor).darken().toString()
}
@computed shadow() {
return "2px 2px " + this.petColorDarker
}
@observable petSize = ""
@computed borderStyle() {
switch (this.petSize) {
case "Small":
return "dotted";
case "Medium":
return "dashed";
default:
return "solid";
}
}
@computed headerSize() {
switch (this.petSize) {
case "Small":
return "12px";
case "Large":
return "60px";
default:
return "30px";
}
}
}Ну и то же самое с разделением:
class PetName {
@observable value = ""
@computed header() {
if (this.value) return "My Pet " + this.value
return "Enter Pet Details"
}
}
class PetColor {
@observable value = "#000"
@computed colorDarker() {
return tinycolor(this.value).darken().toString()
}
@computed shadow() {
return "2px 2px " + this.colorDarker
}
}
class SizeToBorderStyle {
@observable size = ""
@computed borderStyle() {
switch (this.size) {
case "Small":
return "dotted";
case "Medium":
return "dashed";
default:
return "solid";
}
}
@computed headerSize() {
switch (this.size) {
case "Small":
return "12px";
case "Large":
return "60px";
default:
return "30px";
}
}
}
class MyComponent {
petName = new PetName
petColor = new PetColor
sizeToBorderStyle = new SizeToBorderStyle
}Вариант с декораторами тоже рассматривался: https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md#type-issues-with-class-api
В итоге решили на stage-2 proposal не ставить, потому что рискованно.
Кроме того, одним из достоинств Vue считается возможность работы безо всякой сборки, а использование декораторов этому явно будет мешать.
В итоге решили на stage-2 proposal не ставить, потому что рискованно.
А риск-то в чём? Что их выпият из тайпскрипта? Сомнительно.
А на счет того что typescript начнет противоречить стандарту ES — тоже весьма сомнительно. Ведь он изначально позиционировался как надмножество над ES.
Пока правда не понятно как они будут выкручиваться из данной ситуации с декораторами
Чем больше людей будет использовать декораторы и тайпскрипт, тем быстрее декораторы и типизация появятся в JS.
Так проблема-то была в декораторах или в коннектах? Если что, connect (если вы имели в виду функцию из redux) можно и как обычную функцию вызвать...
А вот использование декораторов на свойствах как раз позволяет сделать так, чтобы компонент "дергался" когда нужно, а не на любое обновление стора. Но это придется от redux к mobx перейти.
А что за бардак был с mobx?
Дожили. Люди используют мобх как редакс, а потом жалуются, что сани не едут. Не нужен мобиксу стор в виде дерева.
На самом деле, в mobx можно без труда сделать почти такой же вызов connect как в редаксе, и писать не знающие про стор компоненты:
function connect(mapStoreToProps) {
return function(WrappedComponent) {
return function(props) {
return <Store.Consumer> // ну или inject
{store => <Observer>
{() => <WrappedComponent {...mapStoreToProps(store)} {...props} />}
</Observer>}
</Store.Consumer>
}
}
}Так что инжектить "целые куски стора" в компонент было всего лишь вашим выбором...
Так connect как раз и является усложнением, без него проще как бы.
Но когда "великая проблема библиотеки" решается 11 строками кода — это означает, что и проблема-то была не такая великая.
devtools и mutability
А что с ними не так, кстати?
Ну, у react-devtools известные проблемы с прототипами, акцессорами и обработкой исключений.
Пишем простейший класс...
class Model {
foo = []
get count() {
return this.foo.length
}
}… и получаем Uncaught TypeError: Cannot read property 'length' of null в devtools при попытке экземпляр этого класса просмотреть
Ну так это проблема react-devtools, а не mobx.
const test = new model; console.log(test.count);
Дело в том что свойство и геттер не статистика.
Я ж говорю о том что есть библиотеки, которые не учат разработчиков чистоте кода.Библиотеки ничему учить разработчиков и не должны. Это разработчик должен учиться пользоваться инструментом, которым он работает.
Увы, декораторы JS уже несовместимы с декораторами TS (а также с реализованными в babel, причем дважды). Так что популярность "устаревших" декораторов мало что изменит...
А в чём несовместимость?
Ну так почитайте пропозал-то...
Старая версия декораторов имела сигнатуру (any, PropertyKey, PropertyDescriptor) -> PropertyDescriptor?.
Текущая версия stage2 декораторов: ElementDescriptor -> ElementDescriptor & { extras: Array<ElementDescriptor > }. Как видно, сигнатуры принципиально несовместимые.
Разрабатываемая же версия stage2 декораторов, так называемые static decorators, вообще находятся в отдельном пространстве имен и образуют свой небольшой мета-язык.
Затем, чтобы автодополнение работало и ошибки подсвечивались. Перспектива дебажить пол дня паршивый лендиг из-за мелкой опечатки — такое себе.
Пока правда не понятно как они будут выкручиваться из данной ситуации с декораторами
Скроют за особым флагом в конфиге, так же как они уже делали со всеми ломающими обратную совместимость изменениями...
Лучше смотреть на саму статью, в которой в том числе и упоминается то, что в комментариях любят нагонять панику, даже не ознакомившись с предметом
Вот-вот, я тоже недавно решился немного прокачать фронт, узнав получше про Vue, а тут какие-то перетряски. Простите за нубский вопрос, ибо я бекендер, но… посоветуйте, что есть легковесного для управления стейтом и домом без всяких вебпаков. Я пишу на asp.net, и иногда надо добавить динамики в DOM, а jquery и стейт в инпутах — явно не то, о чем я мечтал )) Или всё норм, уляжется, и можно сразу начинать с Vue 3?
Vue – обсуждаемое API лишь малая часть фреймворка. Директивы, реактивность, синтаксис шаблонов останутся такими же. От этой перетряски больше шуму чем реально ломающих изменений (о чем и статья).
Если же не Vue, то я бы предложил lit-element – библиотеку поверх веб-компонентов.
Не надо бояться вебпаков, в них нет ничего страшного. Говорю как фуллстек, долго бывший бэкендером :) Да и typescript вам как дотнетчику сразу должен понравиться.
При такой постановке задачи vue вполне подходит.
сперва мне тоже не понравился новый синтаксис, но перечитав RFC через пару дней я прям влюбился в него, и жду когда же уже наконец выйдет 3 версия. новый подход это смесь лучшего из объектного стиля и из class components.
а, ну и то, что Эван решил наконец убить миксины в новом синтаксисе, это мне прямо греет душу, ибо миксины это худшее, что есть во вью сейчас.
вам частично уже ответили, но я отвечу более развернуто:
представим, что у вас есть некий компонент страницы, к которому добавлено 2 миксина.
к компоненте страницы есть использование некого метода / выч. свойства или еще чего типа submit. вы смотрите на методы компонента, но там этого метода нет, тут человек с небольшим опытом сломается немного, импорта такого метода тоже нет. знающий поймет, что метод в миксине, но их два, в каком искать? придется открывать оба. А потом окажется, что такой метод есть в обоих миксинах, вопрос, какой из них работает в компоненте страницы?
это была проблема с неймспейсом, мы не можем гарантировать что в разных миксинах не будет пересечение в области имен. могут быть одинаковые методы, выч. свойства, пропсы и прочее.
во вью2 её предлагают решать с помощью договоренностей, что всё, в миксине называется с префиксом $_MixinName_methodName. он решает проблему, но читать становится неприятно.
если миксин не относится к специфичным для вью штукам типа выч. свойств, пропсов и т.д. а является просто сборником методов, то такой миксин должен быть заменен на простой js файл который будет импортироваться в необходимый компонент.
Например:
В админке нужно реализовать возможность блокировать редактирование и создание новостей пока на сайте ведутся технические работы. Я создаю миксин, который раз в 10 секунд get запросом проверяет, не ведутся ли сейчас технические работы, если ведутся то показывается оповещение.
Миксин никак не взаимодействует с компонентом, а просто дополняет его.
Хехе. Очень напоминает knockoutJS (явное описание value(), computed()) и нового reactJS (useHooks). На самом деле концепция с хуками оказалась довольно удобной. Думаю во Vue она тоже "выстрельнет". Разделение на уровне methods, computed и пр. куда менее логично, чем группировка на основе функциональностей. А тут либо хуки, либо миксины, либо инкапсуляция (2-й вариант от Vintage).
Я вот не понимаю, нравится вам v2, не нравится v3 — ну так напишите в ваших зависимостях 2.* и живите счастливо дальше, в чём проблема то?
Верующие всегда с ждут благодатного огня раз в год в великую субботу [ Эван опубликовал коммит 8 июня — суббота что как бы намекает]. И я вам напомню, что его не приход обозначает конец света. Чего, собственно, все и напряглись.
Надеюсь из-за этого недовольства vue3 не окажется с миксинами, компонентами по 500 строк и vue class component.
К тому же очень странно выглядят их заявления о том что новый синтаксис нужен в очень сложных проэктах и местах, но декотраторы и классы это плохо потому что там надо будет билд система и т.д.
Вообщем мне кажеться Эвану и ко. просто очень хочеться в рокет-саенс, при том что их продукт завоевал популярность как раз отсутствием этой самой сложности.
Не понимаю. Народ это фронтэнд. Вы еще не смирились с тем что каждую неделю выходит что-то новое юез оглядки нп обратную совместимость? Тогда вам тут не место
Три основных игрока уже давно закрепились. React/Vue/Angular.
И обратную совместимоть давно никто не ломал. Да и Vue 3 ее не ломает.
Хотя мажорная версия имеет на это полное право
Кпкой там версии у нас последний ангулар?
Не припоминаю, чтобы прям-прям совсем ломали после 4-ки. Депрекейтили — это да, но там достаточно было времени (тем более если использовать всякие штуки типа HttpClient не напрямую, а через свой слой абстракции). Для Rx есть compat-прослойка, опять же.
Тут вот уже дважды упомянули некий Svelte, который "ещё более лучше". Добавил коммент в закладки :)
Лично мне нововведения зашли. Это неплохо позволит сделать код чище, разбить компоненты на составляющие, эдакое движение в сторону single responseability, но от части я и негодование могу понять, порог вхождения это немного увеличит (но вряд ли это будет критично)
Лучше бы уже сделали что-то с vuex, чтобы оно было не stringly typed. Бизнес-логика-то именно там находится, а не в компонентах.
Поправьте меня если я не прав, но бизнес логика должна хранится в соответствующем слое, а vuex как раз только для хранения данных и мутации стейта.
Я как-то слабо себе представляю, как это — еще один слой с бизнес-логикой. Данные же должны лежать в сторе, и работать с ними можно только из мутаций. Ну то есть либо какие-то пляски с бубном чтобы синхронизировать эту самую бизнес-логику и стор, либо перемешать их до степени слияния (и в чем тогда смысл).
Мутации и геттеры очень хорошо покрываются тестами, и этим надо пользоваться, КМК.
DI штука хорошая, но я не видел фреймворков, которые бы мне реально понравились. Вообще было бы крайне интересно поглядеть, как всё это у вас выглядит, покажете?
А если у вас бизнес логика хранится непосредственно в сторе как вы ее в таком случае мокаете?
А в чем проблема ее замокать? Содержимое стора это просто POJO. Если вы про тестирование компонентов, так я тестирую именно сам компонент, полагаясь на то что стор работает как надо (т.к. покрыт отдельными тестами).
Иногда, если что-то большое/нетривиальное, я выношу код в отдельные чистые функции, которые потом просто вызываются из мутаций и т.д. Полагаю, до некоторой степени это можно назвать разделением стора и бизнес-логики.
и еще бизнес логика (которую тоже неплохо было бы покрыть тестами)
Ну вот у вас получается, что одна ответственность размазалась по стору и по некой отдельной бизнес-логике:)
Иногда, если что-то большое/нетривиальное, я выношу код в отдельные чистые функции, которые потом просто вызываются из мутаций и т.д. Полагаю, до некоторой степени это можно назвать разделением стора и бизнес-логики.
Пожалуй я об этом и писал, вообще для DI в чистом виде фреймворк использовать необязательно, можно инжектить перед инициализацией вьюкса, тут как по мне проблем нет (да и в самом вью неплохой ioc).
Ну вот у вас получается, что одна ответственность размазалась по стору и по некой отдельной бизнес-логике:)
А вот почему размазалась я не догоняю, разная же ответственность) бизнес логика не должна быть привязана к vuex. Во вью хорошо что кроме вьюкс по сути и нет ничего для стейта, но если рассматривать другие фреймворки, где для хранения стейта можно использовать не 1 механизм, то как тогда рефакторить код в случае смены стейта? перепиливать весь функционал? Это по меньшей мере предполагает что код открыт для изменения (а не для расширения). p.s. не холивара ради.
разная же ответственность
Ну как сказать… я считаю что данные и методы их обработки должны находиться достаточно близко друг к другу, ведь одно без другого просто не имеет смысла.
но если рассматривать другие фреймворки, где для хранения стейта можно использовать не 1 механизм
Ну это уже какой-то уж очень теоретический случай:) Честно скажу, реакт я уже здорово подзабыл, с хуками и контекстом даже не пробовал (вот там пожалуй да, стоило бы выносить бизнес-логику отдельно), а в ангуляре стейт и так хранится и управляется в отдельных сервисах. Или вы и в ангуляре пишете отдельный сервис для хранения данных и отдельный для работы с ними?
как тогда рефакторить код в случае смены стейта?
Да как обычно, нет?:) Мне моя IDE позволяет рефачить что угодно без особой головной боли.
В общем, вы меня пока не убедили, хотя, безусловно, дискуссия интересная и приятная:)
В общем, вы меня пока не убедили, хотя, безусловно, дискуссия интересная и приятная:)
Это радует) а то я уж было подумал что слишком загоняюсь.
Да для вью пожалуй могу согласиться (но я все равно перестраховываюсь в этом плане и стараюсь выносить логику).
В ангуляре как раз да) выношу в отдельные сервисы(тут под сервисом я имею ввиду класс/функции для обработки данных), был случай когда достаточно большой легаси пришлось переписывать с сервисов на стейт, и лично мне переносить функционал было проще, просто дергая нужные методы из тех же классов но уже в экшенах и эффектах. К тому же, логика для работы с данными может быть переиспользована и в других частях кода.., либо в разных частях работы со стейтом.
это просто POJO
Что забавно — термин означает Plain Old Java Object, и используется программистами на других языках именно в такой форме, хотя Java иногда и не пахнет.
Наверное от того, что никому не хочется всерьёз дропнуть оттуда "J".
Plain Old JavaScript Object в данном случае:)
Еще встречал вариант POCO (С++/С# Object).
Я бы не очень полагался на urbandictionary (откуда slangdefine явно парсит контент).
const sharedComputeds = {
petColorDarker: function() {
return tinycolor(this.petColor)
.darken()
.toString();
},
shadow: function() {
return "2px 2px " + this.petColorDarker;
},
}
export default sharedComputeds;
// -------
import { petColorDarker, shadow } from './sharedComputeds';
const MyVueComponent = {
data() { /* ... */ },
computed: {
petColorDarker,
shadow,
}
}
Это, как говорится, слишком много хорошо уже не очень хорошо.
Темный день для Vue.js