Comments 54
Так во вью четко описано, почему менять пропсы - зло - и это реально так. Если вам нужно менять пропсы где-то - значит ваша архитектура с запахом. Для всего остального можно использовать что угодно, например event-driven, provide/inject и тд.
Computed работает абсолютно четко, если четко понимать, для чего вы хотите его сделать.
Вообще, у меня за годы работы с вью не было ни одной описанной вами проблемы, при этом у нас 3 крупных SPA с нагрузкой до 10000 пользователей.
Ну и практически все остальное, из того, что вы описали - это из разряда плохих советов.
Вы реально Vue знаете? Сколько опыта у вас в нем?
А то может дело не в Svelte и Vue, а в вас - уж извините.
у нас 3 крупных SPA с нагрузкой до 10000 пользователей
тактический вопрос, помогите советом.
есть js модель seatrip (прогулка на яхте), делаем бэк-офис чтобы можно было добавлять/убирать гостей, назначать яхты, капитанов, рисовать календарь.
есть у прогулки период времени и дата, который представлен в виде Value-Object'а (в нем - datetime начала прогулки и количество часов).
есть форма, где эту дату пользователь может менять.
есть компонент, рисующий форму ввода нового периода времени, в котором нужно отрисовать текущие.
Хочется чтобы компоненты (вроде SeatripTimePeriodInput) работали с value-object'ами через v-model, или prop+event.
В текущем виде мы через пропс спускаем компоненту VO с текущим значением, пользователь меняет значение в инпуте , компонент создает новый VO из пользовательского ввода, поднимаем ивентом новый VO на уровень формы, там подставляем в модель, узнаем ошибку, блокируем сохранение (т.к. есть ошибка), спускаем сообщение об ошибке в компонент, компонент увидев сообщение об ошибке рендерит ее и меняет статус на invalid.
Везде в туториалах counter'ы и скалярные значения, которые легко и весело реактивятся, а с моделями (которые сильно сложнее чем get/set) и объектами никто как будто дела не имеет.
Vue заворачивает объекты в свои proxy, заставляя делать toRaw/markRaw, writable-computed, выдумывать трюки по выводу ошибок рядом с формой (если на уровне компонента данные валидны, а когда попадет выше - окажется что нет, и приходится в пропс спускать компоненту сообщение об ошибке для пользователя), следить за изменениями в форме через watch, и прочие странные вещи.
Ощущение, что мне намекают, что я делаю что-то не так, и надо на уровне формы разваливать value-object'ы на скалярные значения, чтобы ниже, на уровне компонентов каждого отдельного поля работать уже с ними. Или выкидывать из головы все DDD'шные/ООПшные вещи и учиться как-то уж сильно иначе все это делать, потому что во фронтенде какая то альтернативная линия времени.
ЧЯДНТ?
Судя по описанию, вы и правда что-то сильно делаете не так. Для работы реактивности нужно 1 раз обернуть модель в прокси и всюду таскать этот прокси, всяческие toRaw и watch нужны для передачи объектов за пределы области ответственности vue.
По поводу паттерна Value object из DDD — такие объекты неизменяемые, им бы Object.freeze вызывать. Когда я последний раз смотрел на vue, Object.freeze предотвращал создание проксей и прочих обёрток.
Вот что делать с многоуровневой валидацией — сказать не могу, ни разу не встречался.
Или выкидывать из головы все DDD'шные/ООПшные вещи и учиться как-то уж сильно иначе все это делать.
ООП совершенно точно выкидывать не нужно, им, напротив, надо активно пользоваться при создании моделей.
Для работы реактивности нужно 1 раз обернуть модель в прокси и всюду таскать этот прокси, всяческие toRaw и watch нужны для передачи объектов за пределы области ответственности vue.
Ну так это то что мы и пытаемся делать, потому что работа с моделью не сводится к геттерам и сеттерам вроде seatrip.timePeriod = reactiveVueTimePeriod.
Там выходит что-то вроде seatrip.moveTo(seatripTimePeriod, yachtAvailabilityService, <...>, notification,) итд итп, и реактивность тут только мешает.
Не очень понятны паттерны работы во vue со своими моделями, сервисами (js кодом который вполне работоспособен отдельно от vue).
Идея в том чтобы vue занимался формочками, собирал в своих формочках доменные объекты (entities, valueobjects, aggregate roots etc), и передавал уже в чистом виде в домен, а потом собранный агрегат/сущность в репозиторий, который из доменного объекта соберет DTO и отправит на апишку. Если захотим завтра переехать с vue на другой замечательный фреймворк - берем с собой домен, и делегируем задачу "собирать доменные штуки" другому замечательному удобному инструменту.
Но тут утыкаешься в то, что vue как-то сильно возражает против такого с ним обращения, и надо вот иначе как-то. Как - непонятно.
Зашивать всю доменную/бизнесовую логику прям в компоненты?
Если у вас ViewModel, то реактивность мешать не должна. Метод moveToDate будет вызван для прокси, что-то подсчитает, в конечном счёте выставит свойства теми самыми простыми присваиваниями — и vue благодаря проксе это увидит.
А при передаче за пределы слоя ViewModel это дело да, надо отрывать от vue. Тут помогает считать вью-модель и DTO или там доменный объект двумя совершенно разными типами, даже если TypeScript с этим не согласен. Относитесь к преобразованиям туда-сюда не как к борьбе с vue, а как к преобразованию из одного типа данных в другой.
Скажем, когда вы отправляете http запрос — вам же не придёт в голову писать fetch({ body: JSON.stringify(this) })? Наверняка в this есть куча свойств которым нефиг делать в запросе, и даже если их там нет — надо расчитывать что однажды они объявятся. Вот и с передачей объектов в доменный слой или куда-то ещё работает тот же принцип.
Если у вас ViewModel, то ...
Ну так компонент это и есть viewModel: есть доменная модель, компонент берет из него данные и из них создает свое состояние, а когда меняем состояние в компоненте - вносим изменения в доменную модель. Это и есть viewModel: мост между view и model
реактивность мешать не должна
Ну, я не могу использовать приватные свойства #propertyName, и вынужден их раскрывать, потому что в прокси не заворачивается, и таким образом вся инкапсуляция идёт по одному месту.
Вижу 2 варианта дизайна:
в компоненте формы сделать реф с доменной моделью (
const seatrip = ref(seatrip.plan(...))), разбирать модель на рефы (const seatripDate = ref(seatrip.getTimePeriod().getDate()...), эти рефы передавать вниз инпутам (<SeatripDateInput v-model="seatripDate" />), в компоненте формы вешатьwatchна каждый реф (watch(seatripDate,...)), внутриwatchмутировать модель (сюда же обработка ошибок и обновление связанных полей) и обновлять тут же обновлять реф доменной модели (seatrip.value = newSeatrip).
попахивает.
можно вместо разбора модели на отдельные рефы все это завернуть в DTO'шку, но суть не изменится: поддерживать и трогать это будет страшно и больно
сломать инкапсуляцию в доменных моделях (заменить приватные свойства публичными), в компоненте формы сделать реф с доменной моделью (
const seatrip = ref(seatrip.plan(...))), спускать конкретным инпутам доменную модель (<SeatripDateInput v-model="seatrip" />), они делают с ним что считают нужным, и возвращают компоненту формы новый измененный доменный объект
Первый - кривой и страшный, второй компромиссный настолько, что неприемлемый.
Выбор не очень :)
Компонент — это View, а ViewModel должна идти к нему отдельно.
Ну, я не могу использовать приватные свойства #propertyName, и вынужден их раскрывать, потому что в прокси не заворачивается, и таким образом вся инкапсуляция идёт по одному месту.
Да, приватные свойства не работают, их специально делали так чтобы они не работали с проксями. Просто не используйте их, как-то же без них кучу лет обходились. Можно использовать TypeScript, там свои soft-private свойства есть.
Или дождитесь пока во vue сделают наконец-то модели как в mobx, через декораторы, благо новые декораторы умеют работать с приватными полями. Или сделайте аналогичную библиотеку сами, там вообще несложно.
А, да, из ваших способов правильный второй, только слова "доменная модель" надо заменить на "view model". Компоненты должны работать именно с ней, с доменной моделью при её наличии работать будет уже VM. Там даже v-model не нужен, у VM своя внутренняя мутабельность должна быть.
Если же компонент настолько простой что полноценная VM ему не нужна — передавайте ему readonly через v-model.
А что же плохого в изменении пропсов?
Распространённая реализация, в которой свойство является отдельной переменной, ведёт к тому что эта самая переменная получает изменения сразу из двух источников. А это нарушает правило однонаправленного потока данных и приводит к трудноустранимым багам.
Вот если изменяемое свойство биндить не как переменную, а как get/set канал (или пару из значения и события) — такой проблемы не будет. Но так мало кто умеет. React так не умеет, Angular так не умеет, Vue вроде бы умеет, Svelte снова, кажется, не умеет.
Иронично что автор считает изменение props достоинством Svelte, хотя именно Vue справляется с этой задачей лучше.
В статье не говорилось что надо постоянно менять пропсы. Конкретно в моей задаче(задачах) есть места где нельзя трогать пропсы, также есть места где это значительно ускоряет написание и понимание кода. Также я не призываю всех делать так, я говорю что лично для МЕНЯ это то что надо. Я не спрашиваю как надо и не учу. Или мне начать переписывать работающий проект так как "правильно"?
Гет сет это тоже самое изменение или получение. Нет никакой разницы за исключением некоторых плюшек. А если мне они не нужны и мусорят код? Да и если никто из знаменитой тройки так не умеет, то зачем оно вообще надо? Может потом - да, но сейчас - нет.
Вью вообще запрещает менять пропсы. А делать storage или this.$parent.value=value или что-то подобное не очень-то удобно.
Я вообще-то приводил ниже код на vue. Чем он принципиально отличается от изменения пропсов в плане удобства? И нет, необходимость создавать computed вообще не является проблемой, потому что этот код можно вынести в хелпер.
При этом, как только вам понадобятся полноценные get/set — вы просто возьмёте и сделаете их вообще не меняя остальную часть программы.
В статье я написал что использовал опшнс апи.
Насчет кода, не спорю. Он хороший, но черезчур непонятный для человека который не использует композишн апи. К тому же свелтовский = намного очевиднее, понятнее и читабельнее чем то что в этом коде. Легче напечатать один знак равно, чем функцию чтобы объявить компьютед
В старом api аналогичный трюк тоже можно сделать. При использовании своих хелперов бойлерплейта в компоненте окажется даже меньше.
Так старый апи Эван будет дропать. А новый апи мы видели из вашего же кода, что он не такой очевидный как свелт. Да и вообще, Эван не дурак, и сделает все таким же легким как и свелт. А зная его, можно предположить что все будет намного удобнее и оптимизированнее чем свелт(хотя вспоминая что в vue 3 пропсы были в атрибутах тэга, то все-таки имеются сомнения). Так что не нужно делать из вью идола.
Изменение пропсов влечет за собой изменение направления потока данных, а это, в свою очередь, приводит к очень сложнообнаруживаемым багам (например, петлям пересчета).
Если нужно что-то 2-у или n-направленное (по зименениям), нужно использовать не пропс, а что-либо другое - шину например - я про это выше писал.
То есть плоха реализация во Vue, а не изменение пропсов само по себе.
А причем тут Vue? Речь про направление потока данных.
В Vue можно писать и без пропсов - если очень хочется, с использованием чего-либо другого для данных - стора, шин, прокси и т.д.
Но если хочется использовать пропсы - то лучше придерживаться однонаправленого потока данных, в каком бы фреймворке это не происходило.
При том, что в более других фреймворках изменение пропсов не вызывает никаких проблем.
Еще раз - проблемы возникают не из-за фреймворка, а из-за множественных источников изменения. От фреймворка в данном случае ничего не зависит, можно и во Vue, если очень хочется, изменять пропс (через функцию, например).
Но потом отлавливать где же что установило некорректное значение, и почему появилась петля в данных будет вашим личным адом.
Ещё раз - в более других фреймворках никаких адов и петель при этом не возникает, а вы всегда знаете кто может установить новое валидное значение, а кто это действительно делает.
Вы мои комментарии выше перечитайте еще раз - у меня где-то что-то написано про фреймворк? Речь про данные, а не про фреймворки - когда получится это осилить - можно будет продолжать разговор.
Вот так вот стараешься поделикатней очередного джуна направить в правильном направлении, а он намёков не понимает и строит из себя не весть что.
Зря вы игнорируете влияние фреймворков. Рассмотрим следующий компонент vue:
<script setup>
import { computed } from 'vue'
const props = defineProps(['msg'])
const emit = defineEmits(['update:msg'])
const msg = computed({
get() { return props.msg },
set(value) { emit('update:msg', value) },
})
</script>
<template>
<input :value="msg" @input="msg = $event.target.value">
</template>Шаблон тут выглядит так, как будто в нём происходит присвоение свойству… между тем, поток полностью однонаправленный.
Тут пример по интересней. Во Vue это через жопу, конечно, делается.
Фреймворк это поделка человека и говорить что он ни на что не влияет это глупо. Почему есть столько разных видов ножа, пил, отверток, плоскогубц? Потому что у разных людей разный взгляд на то как оно должно быть и как должно выглядеть. В альпинизме 2 градуса ледового инструмента влияют на то вернется альпинист живым или мертвым(то есть не вернется). Один изготовитель сделает наотмашь, зато красиво. Другой учтет это и сделает как надо. Третий добавить другую фичу со своими решениями.
Здесь мы говорим не об инструменте, а о фреймворке. Почему люди не пишут на двоичном коде? Потому что вышел фреймворк под названием ассемблер. Почему большинство не используют ассемблер? Потому что вышел под него вышел новый фреймворк с++. И так далее. Хоть и используют по сей день, но только для определенных задач. Сейчас меня будут ругать что я путаю между яп и фреймворком, но дело в том что тут суть одно, что новый язык разработать чтобы было легче, что новый фреймворк для этого языка. Ибо все эти фреймворки это всего лишь новый язык, который компилируется в старый язык. Это все - инструмент, несмотря на то как оно называется, яп или фреймворк.
Фреймворк, влияет на все. У каждого человека свой взгляд. Кому то нравится свелт, а кому то вью. А кто то просто не хочет переучиваться на новое.
В React тоже самое соглашение об однонаправленном потоке данных. Props are immutable—a term from computer science meaning “unchangeable”.
при этом у нас 3 крупных SPA с нагрузкой до 10000 пользователей.
В чем разница для фронта 1 юзер или 10000?
Разница в оптимизации и сложности этого фронта.
В оптимизации чего именно?
В минимзации всего и вся - обращений к бэку, размера этих обращений, рендеринга, их дебаунс и объединение + универсализации компонент и фронта в целом (из-за огромной фрагментации устройств, с которых сидят пользователи) и тд.
Объяснять это в комментарии долго - это тема целых докладов на хайлоадах.
Есть огромная пропасть между приложениями на десятки пользователей и на десятки тысяч на фронте. Про бэк я вообще молчу.
На мой взгляд там нет огромной пропасти, если мы говорим про фронт. Про сложность я вообще не очень понял, как она коррелирует с количеством юзеров. Сложность на фронте зависит от фич, от поддерживаемых клиентских устройств - да, но не от количества юзеров. В сферических условиях у вас и один юзер может юзать 10 браузеров и 20 разных разрешений экранов, но речь не про это, речь лишь про количество юзеров была. Мне просто кажется немного сомнительным использовать выражение "хайлоад" в отношении фронта. У вас всегда будет 1 юзер пользоваться результатом вашей работы. В отличие от бэка, в котором как раз эти 10 тыс юзеров придут в одном место. Да, вы можете повлиять на нагрузку проекта в целом, если на фронте кривые запросы или их огромное количество, но чаще это всё-таки проблема бэка, либо решение совместное, либо вообще решение уходит в UI/UX, чтобы разбить экран на несколько или что-то в таком духе. Решения тут больше логические, чем именно какие-то архитектурные или оптимизационные, как в случае бэка. Могу ошибаться, но куда чаще, если от количества запросов с фронта падает проект, то решать проблему как раз пойдут бэкендеры на своей стороне и очень редко фронты. На бэкенде она во-первых, точно решается, а во-вторых, там всё равно всегда необходимо быть готовым к росту нагрузки и с ростом проекта такая проблема возникает почти всегда, в отличие от фронта.
Извиняю. Честно, опыта много. Но именно в команде программистов очень мало.
Насчет изменения пропсов, а вы не думали что есть экзотические ситуации в которых пропсы поменять легче чем вот это вот все. В моем проекте пропсы меняются только в определенных компонентах которые завязаны на определенной странице. Рич Харрис сделал это, значит он посчитал это нужным, встретил задачу в которой это надо и тд. Мой опыт показывает что такие задачи есть. Мне так легче и быстрее нежели чем искать нужную архитектуру. Ибо раньше я учил и учил, да ничего толком не получалось. Сейчас перешел от теории к практике и все идет невероятно быстро. Ибо программирование ради программирования? Архитектура ради архитектуры? Правильность ради правильности? А зачем, если это не несет никакой пользы. Допустим, я изучил всевозможные архитектуры, способы, языки, алгоритмы и тд, и что? Какая от этого польза если я в жизни не сделал ничего полезного людям, которые не программируют. Кроме того, все эти принципы, архитектуры, фреймворки и тд, каждый год меняются, появляются новые, а бизнес как нанимал неучей(имею ввиду людей не знающих это все) так и будет нанимать. Другими словами, пока один 10 лет пишет все как надо, другой за 2 недели напишет все кое-как, но он быстрее заработает на этом и наймет того кто напишет все как надо.
А также, я извиняюсь, менять пропсы - зло? Что это значит? Я думаю вы хотели сказать - неприемлемо, плохо и тд. Но честно, каждый сам должен для себя решить - подходит ли мне это решение в данной задаче или нет. Нельзя абсолютно отказаться от всего и сказать что твой инструмент пуп земли. Ибо если бы такой инструмент был, то новые версии его не выходили бы. Да и кто вы такой(не хочу оскорбить, а лишь спрашиваю в глобальном плане), чтобы решать что изменение пропсов это абсолютно плохо для абсолютно всех людей. Мне кажется, что такое не может решать человек, ибо у каждого свой опыт, а даже если он учился у кого-то, на практике, из книг, у других людей и тд, то это все равно опыт, даже если это опыт многих людей, то он все-равно ограничен этими людьми. Атеисты абсолютизируют науку, но наука тоже чей-то опыт. И откуда мы знаем что этот человек не ошибся в своих суждениях, или этот эксперимент был частным случаем и общий случай работает вообще по другому? Так что вы не можете сказать что изменение пропсов - зло. Вы можете лишь сказать - ты в праве делать что хочешь если это не вредит мне каким либо образом, но у этого есть такие то риски и недостатки которые я заметил, и я считаю что правильным будет делать не это а вот это.
Как я и говорил, в моем частном случае, когда я работаю в одиночку, я решил, что наиболее быстрым для меня будет изменение пропсов. Я до этого додумался сам, и каждый кто прочитает или не прочитает данную статью должен решить сам что ему делать, менять пропсы или нет. Может он и не знает что такое пропсы и ему это не нужно? Не надо быть адептом чего-то, ибо программирование это всего лишь профессия. Чатжпт показывает, что скоро программирование вообще станет другим. А с приходом в обиход квантовых компов так вообще все перевернется.
Самая главная фича лично для меня это способность изменять пропсы компонента
Кто вам сказал, что менять props это замечательно и так нужно делать всегда? Вы не меняете props для компонента, к сожалению, вы меняете state, если судить по примеру, который вы привели.
Не знаю как вам, но в каждом проекте я сталкивался с необходимостью менять пропс
никогда с таким, лично, не сталкивался, сколько бы проектов не было за плечами.
И никакой тайпскрипт не нужен. Честно, ненавижу тайпскрипт.
TypeScript - не зло, которое нужно ненавидеть, но "на вкус и цвет..."
В реакте есть чудо юзэффект. У вью тоже есть computed, но почему то именно в моем коде мне приходилось всяческий изощряться чтобы заставить его работать.
Как это логично, не справились вы - но вините в этом инструмент. Это звучит так, "У меня не получилось забить гвоздь, виноват молоток" :)
If-elseIf-else, await, store, events
"Смешались в кучу кони, люди..." (с) М. Лермонтов. Бородино
На пункте "Special elements" я устал читать заметку автора о том, что "молоток не забивает винты, а отвертка не закручивает гвозди"... :)))
Это дело автора, его личное мнение и личная позиция, с которой спорить не буду, но дам один маленький, ничтожный совет: "Наполните заметку полноценными примерами как во Vue, так и на Svetle, чтобы у читателей была возможность в сравнение"
Справедливости ради, export let — это именно что свойство компонента. У состояния нет части export.
Так если это решает мою проблему в моей конкретной ситуации, то что в этом плохого? Хочу менять пропсы, так я сам до этого додумался, никто не говорил что надо менять, наоборот, многие говорят что нельзя менять. Но что в этом плохого? Что для русского хорошо, то для немца...
Я и не говорил что тайпскрипт - зло. Перечитайте статью. Да и что значит что только зло можно ненавидеть? Если вы ударить 10 раз об косяк мизинцем, то возненавидете косяк, разве это говорит что косяк - зло? Мне кажется, что многие программисты оперируют словами, которыми они не имеют право оперировать и вообще не понимают как их использовать. Например, называть что то злом. Чтобы называть что то злом, надо быть Господом-Богом, который обладает объективным знанием. Человек не может делать этого, так как у него есть только частный опыт(либо свой, либо чужой). Например, причинение вреда - это зло? Нет, для завоевателя, это добро, для маньяка тоже, для слабого человека - зло. Как видно, у каждого свой опыт. Так что хватит оперировать этим словом. В статье же я ничего про зло не писал, я написал лишь свои ощущения. Там нет агитации, призыва делать так как делаю я. Там всего лишь мой опыт, которым я и поделился. Это не учебный материал.
Насчет не справился я - повторяю, эта статья не критика. Эта статья - не учебный материал. Эта статья - не агитация на то чтобы бросить все технологии и перейти на мою технологию. Эта статья - это то что я поделился своими ощущениями от перехода с одной технологии к другой учитывая мой опыт и тд.
Наполнять ничего не намерен. Это не сравнительная статья. Я здесь не сравниваю два фреймворка. Я здесь передаю свои ощущения от перехода. Это обзорная статья. Никого не агитирую. Там нет такого. Перечитайте статью.
О, сколько вам открытий чудных, ещё в пути том предстоит..
У нас в компании пытались внедрить Svelte как альтернативу React для менее скиловых разработчиков, которым лень вникать в React, его жизненный цикл и это все. По итогу оказалось что изучать новый шаблонный язык, способы объявления биндингов и вот это все ОРИГИНАЛЬНОЕ в несколько раз сложнее, чем использовать JSX с нативными функциями, а сложность приложений несоразмерно выше, чем сложность инструмента. Тоесть у непрофильных разработчиков (биоинженеров) изначально не было шансов на фронте. Мой вывод с тех пор - чем ближе к нативному инструменту - тем лучше; поэтому я выбрал React.
Angular тоже не плох, но с другой стороны. Нативного там маловато, но это классический энтерпрайз фреймворк, как .NET. И если ты нанимаешь на работу ангулярщика, ты с очень большой точностью можешь определить его скилл; стиль проекта жестко регламентируется фреймворком; винтики заменяются по щелчку пальцев; ЭНТЕРПРАЙЗ!11
Все остальное делает ставку на уменьшение количества кода и увеличение количества подкапотной магии, что кажется мне лично вредным движняком, потому что ведет большое количество начинающих разработчиков не по пути изучения языка и базовых технологий (JS, DOM, CSS) а по пути изучения свистелок и перделок.
Каждый раз, читая подобные статьи, я убеждаюсь в том, что человек пока еще не пробовал разбираться в сотнях тысяч строк чужого кода, где понятность и простота стОит куда больше чем сэкономленая строчка, прячущая магию под капотом. И именно поэтому ему кажется что вот тут это реализовано лучше, чем там. TypeScript не зло, а способ написать код так, чтобы при взгляде на него было 100% понятно что он делает, какими типами оперирует в этой конкретной строчке. Да, порог вхождения чуть выше, да генерики, но на дистанции оно окупается. Для небольших проектов сгодится любой фреймворк, но стоит ли тратить время на его изучение, когда можно взять более надежный инструмент?
Ну и да. В какой-то момент разница между фронтом и бэком начинает заключаться в том, что на фронте еще и надо сделать красиво :-D
Удачи автору в начинаниях, без этих метаний между технологиями видимо никак. Желаю, чтобы они закончились поскорее и усилия шли на реализацию задуманного, а не жонглирование фреймворками.
Честно скажу, что действительно устал метаться между технологиями. Но так понимаю что это проблема не в моем профессиональном опыте, а в уверенности в себе.
Также, не понимаю, в чем может свелт быть сложным? Реакт намного сложнее, учитывая что надо много всего понимать. Полагаю что это именно опыт разработчиков помешал им пересесть на свелт, а не его сложность, хотя не осмелюсь судить, ибо не знаю всех обстоятельств. Климов как-то говорил что - переучить людей с второго ангулар на третий сложнее чем научить новичка третьему)))
Ангулар не понравился из за оверинжиниринга, но честно не пробовал его никогда.
Насчет сотни тысяч строк кода, честно, я не хочу стать профессиональным программистом, который меняет несколько работ и разбирает разные проекты или делает их. Вернее хочу, но в приоритете для меня не знания ради знаний, а делать продукт который решает какую то понятную мне задачу. Хочу сказать что я смотрю на все не с точки зрения программиста, а с точки зрения бизнесмена, которому надо чтобы все было готово "вчера". Имею ввиду что я хочу открыть стартап и быть главой. Устраиваться на работу и подчиняться чужой воле(как говорит мой наставник) мне запретил наставник.
Ну и спасибо за пожелания. Но видимо метание между технологиями никогда не закончится, так как идеального айфона нет, иначе новый не выходил бы.
Если вам что-то запрещают - вы уже подчиняетесь чужой воле :)
В программировании знаний ради знаний не бывает. Любой опыт пригождается, особенно полученный в самом начале. Чем качественнее он будет - тем лучше.
В ситуации, когда хочется рулить бизнесом - нужно наверное отдать дело в руки профессионалов и сосредоточиться на решении бизнес-вопросов, например где взять денег на этих профессионалов :) Я к тому, что программирование это ремесло, его надо изучать, вникать, любить ну и вот это все. Просто так с пары кнопок может что-то и получится, но скорее всего совсем не то, чего ожидаешь.
Я самоучка, потратил на это дело около 20 лет и да, в начале было тяжело, но интересно. "Дядю" всегда рассматривал с позиции - этот чел меня учит да еще и денег сверху платит. И для меня это всегда работало ) Ну если запрещают - куда деваться.
Метание закончится, когда надоест тратить время. Возьмите любой инструмент, углубите знания в нем, реализуйте задуманное. Когда настанет время для следующего проекта - недостатки текущего инструмента будут очевидны, а накопленный опыт подскажет какой следующий инструмент выбрать, вот и все.
Согласен со многими пунктами. Но в бизнесе только владелец должен принимать важные решения. Например, решение передать выбор стека технологий в руки профессионалов. Иногда профессионалы не могут выбрать что-то из за того что слишком много знают и видят слишком много препятствий, проблем, ограничений.
То есть, я считаю что процесс происходит так - проф говорит - я выбрал вот это. Босс - ну ок. Или босс - нет, мы выберем другое. Даже если босс не прав, то это все равно его выбор, так как он должен исходить из позиции лидера.
Мне вспоминается история Генри Форда. Он сказал своим профессионалам - сделайте так чтобы весь мотор был в одной металл. коробке. Они же говорили - это невозможно потому что то-то и то-то. Он сказал - сделайте. И так профы начали делать все возможное. Может первоначально и в уродливом виде, на что Генри говорил - Вооот, молодцы, теперь еще компактнее. В итоге сегодня мы не можем представить себе моторы 20 века. Хочу сказать, да, владелец должен отдать в руки профов, но то что он отдает их в руки профов это уже решение самого босса.
Также вспомнился случай Билл Гейца. Он с партнером в гараже замутили бизнес, а когда он разросся, то Билл отдал управление менеджерам, а сам занялся программированием.
Я тоже самоучка. Только не 20 лет))) Хотя сегодня самоучизм дается значительно легче ввиду того что есть всякие гуру вроде Шемседдинова с открытыми курсами в ютубе и сайты типа метанит.
Насчет метания, думаю что в современном мире где каждые 3-4 года выходит новый инструмент в рамках одной технологии(как js в моем случае) думаю что это нормально. , если не прыгать на совершенно другие технологии, а учить по мере необходимости.
Тут основная технология не меняется, а знания по нему только увеличиваются.
Но вот почему то у меня в голове навязчивое желание изучить все и делать все самому. Наверное это из за подсознательных установок типа Ты же мужик, сделай или Сам, все сам. Также влияет и то что я, да и большинство людей - впечатлительные. И на всякие статьи на хабре вроде - Раст будущее, Питон лучший язык и тд начинаем хотеть изучить этот язык и тем самым обойти остальных. Это как с желанием купить айфон, хотя он мне не нужен и в нем отсутствуют те важные функции которые есть в андроиде, например, установка из сторонних источников, чтобы установить newpipe и др. Это, видимо, потешает эго человека, мол я всех обгоню и стану первым который знает все.
Также привитый в школе и родителями перфекционизм только мешает. Из за этого многие(включая меня), не могут принять твердое решение открыть бизнес и др. Данную проблему я вычитал из книги Леонарда Завалкевича - Привычки ведущие к успеху. Автор бьет прямо по больному. Например, сам по себе читал Коран и учил потихоньку. Пошел в мечеть, послушал препода по арабскому, и теперь еле как заставляю себя читать Коран. Это как когда не знал технику бега - обгонял всех соперников, а как только тренер научил технике бега - стал еле бегать да и вообще бросил бег(и в придачу возненавидел).
Самая главная фича лично для меня это способность изменять пропсы компонента. Это то чего мне не хватало у вью и то почему я не перешел на композишн апи(не только из за того что он похож на реакт)
Эмм... вы шагнули мимо концептуальных вещей, вам сюда https://ru.vuejs.org/guide/components/props#one-way-data-flow
Если дочерний компонент может менять пропсы, то весь поток данных становится непредсказуемым — родитель не знает, что его данные внезапно изменились, и это приводит к трудноуловимым багам. Vue специально предупреждает об изменении пропсов, чтобы поддерживать порядок: данные идут сверху вниз, а события— снизу вверх.
Перед тем как писать подобное, вам стоило ознакомиться, почему вью вас ругает, вы, явный косяк в архитектуре, подчеркнули как ПЛЮС, это фатальная ошибка, и ведь дело даже не в фреймворке... хоть на сервере будете писать код, где есть иерархия данных, подобные махинации, это выстрел в себе в ногу, ничего больше.
Представьте ситуацию: у вас есть функция, которая обрабатывает объект с настройками, переданный из другого модуля. Эта функция изменяет настройки внутри себя, например, добавляя значения или модифицируя их. Но другие части программы тоже используют этот объект и ожидают, что он останется неизменным. В результате возникает конфликт: один модуль получил изменённый объект, когда ожидал его в исходном виде, и программа начинает вести себя неожиданно. Такой баг сложно отследить, потому что изменения объекта происходят «втихаря». Вам это ничего не напоминает? Ну, конечно, вы нашли какие-то плюсы там, где их нет и не должно быть :)
Если дочерний компонент может менять пропсы, то весь поток данных становится непредсказуемым — родитель не знает, что его данные внезапно изменились, и это приводит к трудноуловимым багам. Vue специально предупреждает об изменении пропсов
Ну а в $mol_wire владелец не теряет контроля даже при двустороннем связывании. Никаких багов, соответственно, на этой почве не возникает.
Не спорю, сам люблю Vue за two way binding, при грамотном подходе его можно нужно делать контролируемым. Просто вопрос в предсказуемости и простоте потока данных. Односторонний поток минимизирует сайд-эффекты. За удобство двусторонней связи приходится платить: чем больше компонент может менять данные извне, тем выше вероятность неожиданных сюрпризов (а нам ведь не нужны сюрпризы). Это супер важно для крупных проектов, где сотни и тысячи компонентов. Two way binding требует постоянного внимания: нужно всегда держать в голове, что этот стейт в родителе может измениться из любого дочернего компонента. А значит, остальные компоненты, которые его используют, тоже должны быть готовы к этим изменениям. Плохо ли это? нет и да, расширять такую систему не всегда просто и удобно — это и есть цена за удобство двустороннего связывания.
ИМХО, двусторонняя связь удобно, полезно, но не всегда оправдана — проблема в том, что её иногда применяют там, где она вообще не нужна. Главное делать это осознанно: одно дело, когда связь настроена прозрачно и предсказуемо, и совсем другое — когда изменения приходят непонятно откуда. И как сказал выше, во многих кейсах связь на самом деле не нужна, и вариант с событиями будет грамотнее.
Ну вот в $mol_wire его не нужно делать контролируемым, он просто всегда контролируемый и никаких "сюрпризов" не возникает - кому разрешил менять, тот и меняет. И остальные компоненты не надо "готовить" к изменениям, ибо благодаря реактивной системе они всегда к этому готовы. А расширять такую систему - одно удовольствие, так как каждый канал - это точка расширения, которую можно настраивать как хочешь. А всплытия событий в $mol_view вообще нет - есть лишь двусторонний биндинг на каналы, в которые пишутся объекты событий.
Как я переписал свой проект на Svelte