Каждый из них имеет свою ебаную логику

Это 2 разных компонента

Да, я делал процесс оплаты

Запрос мы шлем с формы трансфера

Эммитил события вверх

С данными трансфера и пользователя

Эммитил события вверх

Понял. Я забил. Слишком сложная структура. Я начал путаться в эмитах через 3-4 уровня вложенности

Проще оказалось сделать экшен и ложить ошибки в стейт

Понял. Я забил. Слишком сложная структура. Я начал путаться в эмитах через 3-4 уровня вложенности

Я детали шас не вспомню, но прям большой вложенности там не было

Меня даже один уровень, как в редаксе, сильно напрягает

Я детали шас не вспомню, но прям большой вложенности там не было

Ну вот да. У меня слишком овердохуя всего.

Но я понял твой посыл. Да, в первый мне тоже захотелось юзать вьюкс, чтобы сохранить данные подготовки платежа (id платежного терминала, тип комиссии, список полей и т.д )

Но я понял твой посыл. Да, в первый мне тоже захотелось юзать вьюкс, чтобы сохранить данные подготовки платежа (id платежного терминала, тип комиссии, список полей и т.д )

Не. Я как раз такое не делаю

Там 3 степа

Там 3 степа

Какие?

твоя форма похожа на мою форму регистрации? 1 шаг собрать данные пользовалтя 2 шаг послать ему письмо по почте и по ссылки перейти на 3 шаги формы шаг заполнить данные дополнительные 4 шаг получить подтверждения по почте

Первый высылка Второй подтверждение

6 типов трансферов

У нас 1. Подготовка платежа 2. Создание платежа 3. Подтверждение платежа

Как в каком нить киви, например

У нас 1. Подготовка платежа 2. Создание платежа 3. Подтверждение платежа

Аналогично. Типа данные заполнили. Выслали Подтвердили Показали результат

Аналогично. Типа данные заполнили. Выслали Подтвердили Показали результат

Еп

Но на самом деле это интернет банкинг с упором на конвертацию и продажу валюты

Для одного международного банка

И там до ебени всякой хуйни. Трансферы Покупка и продажа Циклические платежи Сплиты Оформление карт кредитов и прочей хуйни

Весело)

И логики очень много. Поэтому писать все по компоненто (логику) Мы б охерели. Поэтому стандартизируем

И экшен пер апи это идеальный выход

А у меня вот эта форма оплаты в какой-то момент стала нужна как самостоятельный виджет)

Когда 90% логики и стандартизации ответов с сервера проводится в vuex

А у меня вот эта форма оплаты в какой-то момент стала нужна как самостоятельный виджет)

Есть и такие. Но там мы делаем как компонент в компоненте и просто пропсами передаем данные

Это инструмент для управления состоянием приложения

Состоянием приложения. Говоря об авторизации, фактически, это может быть инкапсулированный от основных компонентов модуль, который и будет возвращать состояние приложения, мутировать vuex. Точно так же, как модуль HTTP, который, в свою очередь, может быть прикинут в прото приложения или импортирован в эти же actions хранилища.

А насчёт стандартизации Не я придумал но используем что то типа const sendTransfer = async({commit}, payload) => { const data = Transformer.sendForeign(payload) const request = await Api.sendForeign(data) ....

И такие трансформации обрабатывают данные и до высылки и после получения данных. В них мы парсим данные, заменяем к примеру first_name на firstName и возвращаем стандартизированные данные для дальнейшей работы

Состоянием приложения. Говоря об авторизации, фактически, это может быть инкапсулированный от основных компонентов модуль, который и будет возвращать состояние приложения, мутировать vuex. Точно так же, как модуль HTTP, который, в свою очередь, может быть прикинут в прото приложения или импортирован в эти же actions хранилища.

Ну в общем да, ты можешь прокидывать их как $auth, $http и тыды

А можешь как $store, который это объединяет

Может меня просто редаксом контузило, конечно

Ещё раз скажу, меня просто радует возможность выделить всю жирную бизнес логику в отдельное место и компонентам оставить логику чисто отображения. Это хорошо гармонирует с моим ци

А можешь как $store, который это объединяет

просто в этом случае логика модуля (в данном случае – авторизация) смешается с основной логикой состояния приложения. результаты действий модуля можно отражать в виде его собственных методов / свойств или же, мутировать хранилище (создать поля в стейте, добавить соответствующие геттеры, естественно мутации – их использовать в методах модуля). и дергать уже конкретное состояния в самом приложении из хранилища. или из this.$auth, если он есть в прототипе. вечный вопрос, вьюксить или не вьюксить) так же и с работой с api. модуль http, а где дергать эти данные – тоже вопрос. только с парой отличий: http провайдит, как правило, лишь общий метод для запросов (хуки, интерцепторы, например, для этой же авторизации); сами запросы могут быть использованы из различных мест, а могут быть сугубо частными, и это повод задуматься, выносить их в actions или оставлять в конкретном компоненте.

Ещё раз скажу, меня просто радует возможность выделить всю жирную бизнес логику в отдельное место и компонентам оставить логику чисто отображения. Это хорошо гармонирует с моим ци

добавлю, что у vuex есть возможность создания модулей, что в таком подходе, опять же, избавит от каши в хранилище

Ребяты, посоветуйте, как сделать подтверждение удаления как-нибудь по-простому, используя Bootstrap 4

bootbox.js гады не обновляются до Bootstrap 4

Привет всем. Кто-нибудь скажет в чем преимущество Immutable?

Почему нужно к примеру все время возвращать новый state вместо того чтобы его изменять?

Привет всем. Кто-нибудь скажет в чем преимущество Immutable?

по сравнению с чем преимущество ?

Как это принято у тех кто исопльзует Redux

Они все время пишут так : return {...state, id: someId, first_name: someFirstName}

Преимущество в том, что ты теперь хипстота

А vuex это делается так: state.id = someId; state.first_name = SomeFirstName;

Не нашел для себя конкретного ответа на этот вопрос

Ну серьезно, преимущество (единственное!) в том, что по === два deepEqual immutable объекта всегда равны

и статьи с хабра не подходят?

нет никакого преимущества для вью я для редакса по другому нельзя

Можно для редакса, можно

https://habrahabr.ru/company/devexpress/blog/302118/

Ты можешь deepEqual воткнуть вместо === и тогда ваще все равно, иммутабл не иммтабл

по итогам статьи можно понять, фичи призрачны, проблем достаточно

Можно и с vuex использовать иммутабельность на изи впринципе

Только смысла ноль, потому что вью завязана на мутабельности

Ну да, поскольку об иммутабельности я нигде ничего не нашел. Но это на мой взгляд даже упрощает жизнь

Именно так. Поверь, старый добрый a.foo = 'bar' куда лучше чем a = a.set('foo', 'bar')

Иммутабельности в Vue

Кстати, мб кто-нибудь знает, если ли такая штука для VUEX https://i.ytimg.com/vi/yv5RgBiaUNs/maxresdefault.jpg ?

vue devtools насколько я знаю такого нет

Просто интересно)

Никогда в редаксе ей не пользовался, кстати

Я тоже, но выглядит красиво)

Да и на структуру данных можно посмотреть с высоты птичьего полета

Проще ручками протыкать плюсики, там сразу и сами данные видно

в vue редакс исользуется?

Есть Revux или что-то в таком роде, но насколько это хороший инструмент - хз

в vue редакс исользуется?

Чур тебя

Ещё во вью не хватало этих тонн бойлерплейта

+

я из за редакса реакт не стал смотреть даже

Кстати, мб кто-нибудь знает, если ли такая штука для VUEX https://i.ytimg.com/vi/yv5RgBiaUNs/maxresdefault.jpg ?

есть. поищи в расширениях

есть. поищи в расширениях

Ты уверен? Сам пользовался?

да.

ща поищу

да.

Буду благодарен

Ребят, гитхаб упал?