Anton Saprykin
Саня ты все усложняешь
Anton Saprykin
Надо писать что бы самому в кайф было
Андрей
Каждое дополнительное условие учёта и есть боль при создании воркфлоу потоков.
Да, есть такое. В итоге просто рядом мы имеем набор функций, которые вызываем из компонента, в зависимости от условия.
Anton Saprykin
Для сложных калькуляторов у тебя своя библиотечка со своими тестами.
Александр
Да, есть такое. В итоге просто рядом мы имеем набор функций, которые вызываем из компонента, в зависимости от условия.
Ну ты утрируешь. Набор функций - это конечное состояние уже написанных функций.
Александр
Увязка данных между функциями - это другое.
Александр
Для сложных калькуляторов у тебя своя библиотечка со своими тестами.
Калькулятор - это как пример не обязательный. Можешь свои примеры привести сложных проектов.
Александр
За годы я понял, что сами прогеры (нормальные прогеры, увлеченные люди и творческие личности в одном флаконе) делятся в основе на два типа, те, кто может выточить деталь, но не видит общей картины. И те, кто видит общую картину и может манипулировать глобальными сущностями, но с деталями туговато.
Александр
Но это не точно...
Андрей
За годы я понял, что сами прогеры (нормальные прогеры, увлеченные люди и творческие личности в одном флаконе) делятся в основе на два типа, те, кто может выточить деталь, но не видит общей картины. И те, кто видит общую картину и может манипулировать глобальными сущностями, но с деталями туговато.
Ну, память ограничена у людей. Либо одно, либо другое)
🅅aleriy
@XaveScor "A new developer to the codebase will not struggle to find places where the business logic lives since every module should have a proper name and reference inside the components"
🅅aleriy
https://medium.com/3yourmind/large-scale-vuex-application-structures-651e44863e2f
Андрей
Every menu entry would basically be a module containing several actions, getters and mutations. All those parts are just listed inside a single module file. This will not really scale well, since even modules can get quite large given how much functionality a module needs and result in modules having more than 1000 lines of code.
Андрей
Ну да, vuex нужен для каждого чиха.
Андрей
Создаём себе проблемы, а потом их решаем.
🅅aleriy
тут надо помнить поговорку "заставь дурака богу молиться..."
🅅aleriy
и потом это для "Large-scale Vuex application structures"
Андрей
тут надо помнить поговорку "заставь дурака богу молиться..."
Ну да, vuex нужен очень в малом количестве сценариев.
🅅aleriy
какие то мелкие поделки вполне могут обходиться и без vuex
🅅aleriy
Ну да, vuex нужен очень в малом количестве сценариев.
ну вот у меня ни разу не было проектов где не нужен был vuex/redux/saga/epic
🅅aleriy
там даже redux-thunk не заходил уже
Андрей
ну вот у меня ни разу не было проектов где не нужен был vuex/redux/saga/epic
Как знаешь. Я не полагаюсь на чужие утверждения.
Андрей
Особенно "У меня не было проектов, где я бы не смог обойтись без ...".
🅅aleriy
да как бы нет цели тебя переубедить или навязать мнение тебе
🅅aleriy
просто о разного уровня веб проектах говорим
Андрей
Почему?
🅅aleriy
так то я тоже против стрельбу из пушек устраивать там где пушки не нужны
Андрей
Я не говорю, что подобные интсрументы не нужны. Я говорю, что эти инструменты нужно применять очень тонко. В единичных случаях.
Андрей
Я не "большое приложение === размажем всё в vuex"
🅅aleriy
Я не "большое приложение === размажем всё в vuex"
погоди, вот тут как раз надо сказать, соберем в vuex то что ранее было размазано по компонентам
Андрей
🅅aleriy
в vuex даже саму структуру папок принято называть modules и внутри по модулям все разложить
🅅aleriy
чтобы порядок был
🅅aleriy
чтобы ты знал где какую логику можно найти быстро
Андрей
чтобы ты знал где какую логику можно найти быстро
Ты всё равно ищешь компонент, чтобы найти логику.
🅅aleriy
обращаясь к этой структуре не по именам компонентов, а по назначению сущностей моделей
🅅aleriy
я ищу компоненты только в одном случае - когда есть ошибка отображения
Андрей
обращаясь к этой структуре не по именам компонентов, а по назначению сущностей моделей
Осталось понять как ты узнаешь название назначения сущности.
🅅aleriy
ну ок
Андрей
Глазами просматриваешь?
🅅aleriy
например сущность products в соответствующей модели
🅅aleriy
там есть набор экшинов, которые можно вызывать из компоенентов с параметрами
🅅aleriy
этими экшинами компоненты просят модель измениться
🅅aleriy
забирают данные через геттеры из моделей
🅅aleriy
все красиво и прозрачно
Андрей
там есть набор экшинов, которые можно вызывать из компоенентов с параметрами
Т.е. ты строишь гипотезу, что, наверно, здесь надо писать код?
🅅aleriy
компоенеты ничего не знают о механике этих изменений, они просто делегируют эту работу моделям
🅅aleriy
ну это можно знаешь с чем сравнить
Андрей
компоенеты ничего не знают о механике этих изменений, они просто делегируют эту работу моделям
Ну прекрасно, лишняя сущность.
Андрей
Сам об этом только что написал.
Андрей
Потому что бизнес требования не говорятся в виде "Добавьте функциональность в модель 'бла-бла'". А "хочу фигнюшку здесь на этой странице".
🅅aleriy
например ты начальник и у тебя есть подчиненные
ты как начальник должен предоставить генеральному директору отчет, т.е. срендерить его по данным которые дают твои подчиненные
ты можешь сам собирать их в кучу сидеть из raw даты которую тебе принесут и в ручном режиме эти данные запрашивать с каждого
а можешь просто дать команду, ребята сделайте мне отчет! у вас есть правила по которым его надо делать, занимайтесь
Андрей
И если ты лезешь в хранилище сразу, ну... крут. У тебя весь проект в голове сразу.
Андрей
например ты начальник и у тебя есть подчиненные
ты как начальник должен предоставить генеральному директору отчет, т.е. срендерить его по данным которые дают твои подчиненные
ты можешь сам собирать их в кучу сидеть из raw даты которую тебе принесут и в ручном режиме эти данные запрашивать с каждого
а можешь просто дать команду, ребята сделайте мне отчет! у вас есть правила по которым его надо делать, занимайтесь
Реальный мир на программирование никак не накладывается. Заканчивай с аналогиями. Они не работают.
🅅aleriy
И если ты лезешь в хранилище сразу, ну... крут. У тебя весь проект в голове сразу.
ты vuex расстматриваешь однобоко, ты на него как на глобальное хранилище смотришь
🅅aleriy
надо смотреть на него немного шире
Андрей
ты vuex расстматриваешь однобоко, ты на него как на глобальное хранилище смотришь
Да, потому что нафиг создавать лишние сущности.
🅅aleriy
Да, потому что нафиг создавать лишние сущности.
ну vue компоненты по твоей логике это тоже лишние сущности
Андрей
Я конечно понимаю, что во vue любят создавать новые сущности, но надо иногда останавливаться.
🅅aleriy
можно же просто обходиться document.append(document.createElement('div'))
Андрей
ну vue компоненты по твоей логике это тоже лишние сущности
Нет. vue компонент состоит из 2 частей: из логики и шаблона. Вот в шаблоне пиши отображение, а в логике, внезапно, логику.
🅅aleriy
Нет. vue компонент состоит из 2 частей: из логики и шаблона. Вот в шаблоне пиши отображение, а в логике, внезапно, логику.
для простых случаев это так и есть
🅅aleriy
но когда у тебя модели сложные и должны знать друг о друге все
🅅aleriy
то ты тут в рамках одного компонента зашьешься
Андрей
Все знают о всех.
Андрей
Декомпозиция?
🅅aleriy
хорошо когда у тебя бакенд норм и ты можешь получать данные в нужном виде или юзать graphql для этого
Андрей
Ок, если ты считаешь, что во вью компоненты должны выглядеть как "только шаблон", то без проблем.
🅅aleriy
но часто бывает так, что бакенд на какой-нибудь java и менять его уже никто не собирается
🅅aleriy
Ок, если ты считаешь, что во вью компоненты должны выглядеть как "только шаблон", то без проблем.
ну компонент должен реагировать ни действия пользователя, реагировать на стримы данных
Андрей
Я не говорю, что api должно быть частью отображения.
🅅aleriy
но делать это правильно
🅅aleriy
компонент не должен внутри себя делать ручную работу над обработкой моделей
Андрей
ну компонент должен реагировать ни действия пользователя, реагировать на стримы данных
У тебя по такой логике будет ui kit и компоненты, которые просто агрегируют другие компоненты.
🅅aleriy
он должен сказать getUserList, createUser и т.д.
но там не должно быть логики создания нового пользователя и обработки ошибок связанных с этим