В этом чате. Когда я графкл с реактом сравнил
твое сравнение было не совсем понятным
Nikita
Nikita
не совсем понятно какая скорость исполнения таких штук и какой профит от такого.
Serge
твое сравнение было не совсем понятным
Да я понимаю. Но рубить сразу за что? Я не такой умный и учусь.
А графкл интересен, т.к. щаз как раз бэк с фронтом проектируется
Tom
профит в отличии от использования запросов по ресту?
Nikita
профит в отличии от использования запросов по ресту?
профит ведения стейт менеджера в graph ql
Tom
профит - если рассматривать буквально, по слову профит
Tom
то прибыль начинается с отсутсвием vuex зависимости
Nikita
сколько ты времени слил на то, чтоб вкурить как это все работает и как с этим работать и долго пришлось впиливать все это.
Tom
я встаю в пол пятого утра каждый день, и учусь
Nikita
я постоянно слышу плевки на vuex, но никак не пойму, что с ним не так.
Tom
Просто представьте
Tom
что нам нужно?
Tom
с точки зрения компонента, ему необходимы данные, данные мы достаем с разных мест
Tom
одним из таких мест это удаленные сервера, другим является глобальный стейт и т.д
Tom
но все это данные
Tom
что если мы можем просто выдвигать потребности к данным без дополнительных инструментов
Tom
Громоздко офрмлен код, но для сути
Tom
https://github.com/Akryum/vue-apollo-example/blob/master/src/App.vue
Tom
Я выдвигаю потребности к данным находящимся в разных местах с помощью одного языка. на graphql можно даже к rest сервисам обращаться
Tom
Каждый запрос проходит сверху вниз по стеку links (как правило)
Tom
Nikita
чето
Nikita
ничего не ясно
Tom
не совсем понятно какая скорость исполнения таких штук и какой профит от такого.
Cкорость такая же, graphql transport agnostic, я использую http протокол для передачи запросов от клиента к серверу. Хотя есть одна загвоздка, запрос rest resouce, гораздо короче чем graphql query, поэтому он "тяжелее" для передачи. Но эта проблема решается кешированием запросов, и использование id этих кешей вместо полноценных graphql query
Evgheni
Tom
Некоторое время назад Facebook с их Relay решили эту проблему (частично) предгенерацией id для каждого запроса
Tom
соответсвенно запросы становаться еще короче чем даже у rest ресурсов, мы шлем http://backend.back/id=akbar
🐏 Alexander
🐏 Alexander
в запросе query {
modal @client {
isOpen
}
user (id: 'akbar') {
name
}
}
серьезно, я так что не могу написать обычный АПИ метод!?
Tom
Даже отвечать не стану)
Tom
Всем доброй ночи ребят, да прибудет с вами сила
🐏 Alexander
@eddimensi ну камон -_-
Vladislav
Nikita
Это уже переход на личности
Tom
Serge
Кароч. Какая то хуита - этот ваш граф. Так и запишем
Tom
Не стоит после первого раза прочтения спеки, так горячиться
Nikita
если серьезно, то просто у него есть парог вхождение, но не значит, что это мусор
🐏 Alexander
граф может и не такая уж хуйня для корпораций типа FB, для всех других это конечно ненужная хуйня
Tom
если серьезно, то просто у него есть парог вхождение, но не значит, что это мусор
Я 2 дня просто читал, и понял на 3
Tom
граф может и не такая уж хуйня для корпораций типа FB, для всех других это конечно ненужная хуйня
откуда это у вас берется?
Nikita
я думаю, многие паттерн из redux не сразу поняли, а потом вкурили.
Serge
Прост это выглядит диким оверхеадом. Ну если только для энтерпрайза
Tom
Отсутсвие понимания технологии не обозначает ее сложность
Nikita
на мой взгляд подходит к проектам в которых апишки по кд новые выпускают.
Nikita
у меня был проект и там просто роутов 50-60 было, вот там граф наверно выстрелил бы
Nikita
+ автодока была бы
Serge
Отсутсвие понимания технологии не обозначает ее сложность
Не только сложность. А и колво кода и время на разработку. А это деньги
Tom
Я не о том
Tom
Ты задумывался о причине создания фреймворков?
Tom
Это не просто прилив в мозг очередной дозы фенотропила
🐏 Alexander
а потом от этих фреймворков получаем монстров типа react+redux+redux-form
Serge
Это не просто прилив в мозг очередной дозы фенотропила
Ты работал в команде со сроками , тз и прочим?
или просто физик теоретик?
Tom
Ты работал в команде со сроками , тз и прочим?
или просто физик теоретик?
я работаю в проекте где обычно дедлайн это "вчера"
Tom
я работаю в блокчейн проекте
Nikita
я опять повторюсь, не зря у тебя очки
Nikita
блокчейн, еще одна сложность
Serge
я работаю в проекте где обычно дедлайн это "вчера"
И есть время выпиливать вьюкс и впиливать непроверенные кастомные решения? Ну хз...
Tom
Блокчейн еще одна прекрасная технология
Vladislav
И есть время выпиливать вьюкс и впиливать непроверенные кастомные решения? Ну хз...
ну у кого-то же было время выпилить джиквери и впилить реакт/angular
Nikita
И есть время выпиливать вьюкс и впиливать непроверенные кастомные решения? Ну хз...
Аполло не такое уж и кастомное решение.
🐏 Alexander
с Ильей тоже много кто не согласен
есть такое, но я к тому, что опять же спорная технология, а не "прекрасная"
Serge
ну у кого-то же было время выпилить джиквери и впилить реакт/angular
Ну явно не со вчерашним дедлайном
Tom
Я думаю, можно закончить на том, что каждый сам решает что использовать и когда. Главное, чтобы вы получали необходимы для вас средства и конечно же удовольсвтие.
MXLTN
вопрос - есть какой-то принятый патерн для работы с коллекцией, которая рендерится через компонент и может изменяться пользователем и эти изенения сохраняются на сервер но о них должен знать родительский Vue и сам компонент.
вариант1. компонент занимается отслеживанием изменений и отправлят на сервер и ответ сохраняет у себя в data локально
минус - родитель не знает о том что что-то произошло и изменилось и экзепляр родительский остается старый. можно делать каике-то ивенты и тд - но это уже как-то некрасиво.
вариант 2. компонент не меняет ничего а только файрит ивент на родителя и родитель уже занимается обновленим и отправкой всего на сервек и получением обновленного эксземпляра и обновляет вью.
минус - теряется преимущество разбиения логики. получается компонент только будет рисовать и все, вся логика будет нагружена на родительсий элемент.
как правильно?
Vladislav
Если родителю не нужно знать об изменении чайлда то 1, иначе 2
Anton
а почему ты через пропсы не можешь прокинуть свой массив для всех детей и менять параметры сразу в нем а не создавать over 9000 переменных с времеными значениями и передавать их родителю через события
Max
вопрос - есть какой-то принятый патерн для работы с коллекцией, которая рендерится через компонент и может изменяться пользователем и эти изенения сохраняются на сервер но о них должен знать родительский Vue и сам компонент.
вариант1. компонент занимается отслеживанием изменений и отправлят на сервер и ответ сохраняет у себя в data локально
минус - родитель не знает о том что что-то произошло и изменилось и экзепляр родительский остается старый. можно делать каике-то ивенты и тд - но это уже как-то некрасиво.
вариант 2. компонент не меняет ничего а только файрит ивент на родителя и родитель уже занимается обновленим и отправкой всего на сервек и получением обновленного эксземпляра и обновляет вью.
минус - теряется преимущество разбиения логики. получается компонент только будет рисовать и все, вся логика будет нагружена на родительсий элемент.
как правильно?
Как вариант - Vuex, на сервер отправлять данные через action, получать данные уже из хранилища в нужных компонентах.
Stanislav
Evgeniy
если бы он был не нужен его бы не создавали
Alexey
В тему срача react vs vue. Обидно немного за наш vue https://medium.com/javascript-scene/top-javascript-libraries-tech-to-learn-in-2018-c38028e028e6
Alexander
народ, а что сейчас в тренде, vuetify, bootstrap-vue или semantic-ui-vue? мож еще чего есть?
batkor