Rudex нужен а GrapfQL используется в связки с несколькими серверами от 2-х и более. Это его правильное применение. В остальных случаях используется redux на текущий момент времени.
@@legendarysergeygaming6395 с какими серверами? Зачем GraphQL несколько серверов? В остальных случаях, когда мы не используем Apollo, мы можем пользоваться любым state менеджером: mobx, effector, reatom, recoil
Спасибо за видео, второй раз и опять вовремя, сначала про redux (2 года назад) а теперь про gql! Очень понятно объясняешь, респект! Про TS это конечно супер :)
По поводу контрактности - придется искать баланс между кол-вом запросов и кол-вом данных в каждом запросе. Под каждый чих не будешь запросы слать. Можно конечно говорить о кешировании, но его тоже придется прогнозировать - что будет закешировано на клиентской стороне, к какому-то моменту, что еще нет. В какой момент кеш будет инвалидироваться.
Блин вот я осёл, когда учил реакт (по книжке) пропустил главу с GraphQL потому что подумал, что это что-то про графику)) Впихнул в своё приложение редакс, уже подобрался к саге и тут твой видос, ну все, буду пробовать graph!
@@alexey_horbunov "Реакт быстро" (react quickly) автор Азат Мардан. Но лучше поискать что-то поактуальнее. Например, там нет ни слова про хуки. Описан серверный рендеринг, но без next.js
фу бл. редакс сага, с ужасом вспонимаю времена, когда использовал этот кал. а,да учить это все по книгам не стоит, потому что пока книга пишется и издается, то технология, описанная в ней, устаревает. учитесь по официальной документации
Отлично обьясняешь, сидел 2 часа читал документацию, а тут за 20 минут все по полочкам разложил, респект таким пацанам 23:21 надо передать масив, а пишешь обьект. Полагаю все таки заговорился и передать надо было таки обьект, пральна понимаю?
Спасибо, шикарное видео. Скрипач не нужен. Только вот там еще ерор возвращаются из этого хука, жаль что не дописали немного компоненты для красоты картины.
Вот было сказана что уменьшает время обработки запросов, не совсем понимаю как это. Как в данном случае работают resolve ры GraphQL запросов и как в них должны строятся запросы sql, nosql и чем это отличается от rest-а. Есть кеш, а как быть если кеш устарел, а в базе уже новые книги - получается сначало придет старье, потом дойдет новое, будет обновление на клиенте.
спасибо за ролик! все работало и было понятно до работы с клиентской частью: в файлах .graphql почему то у меня нет никакой идентификации ни "query" ни всего остального и подобного... все подчеркивает красным... почему так может быть?
Немного не понял на примере с книгами. Точнее, в плане использования GraphQL вместо Redux все ясно. Не ясна принципиальная разница (именно в конкретном примере) между GraphQL и классическими запросами REST API. Что тут мы по заранее запрошенному айдишнику запрашиваем каждую отдельную книгу, что там. В чем профит?
@knowcity Скажите пожалуйста, если мы отказываемся от redux и начинаем вместо него юзать apollo client cache, то как быть с изменениями? Менять данные на прямую в кэше graphql?
Тот же вопрос. На таком Hello world примере легко говорить, что redux не нужен. В большом проекте, где нужно локальное состояние, я не знаю как без redux обойтись
@@romuelson нет пока что прорывной альтернативной технологии. Где-то юзают redux, где-то Apollo client, где-то useSWR. Все зависит от масштаба проекта и объема логики на фронте. Мне лично нравится связка Apollo Client/ useSwr для кеширования get запросов и redux toolkit для обработки сложной логики. Кеширование под коробкой хорошо работает ровно до того момента, когда приходится производить сложные мутации данных. Код начинает разрастаться до размеров чистого Redux. И эта проблема, которая толком не решена ещё ни в одной библиотеке полноценно
@@valdik630 Благодарю Вас за ответ, второй день плаваю, в группе телеграмм GraphQL нашел ответ от авторитетного источника: ``` Если у вас redux store только под данные с сервера, то точно переезжайте на аполло клиент. Если в сторе и данные с сервера, и локальные клиентские, то желательно разделить их. И локальные клиентские можно оставить в редаксе. Но там, потом когда смотрят, что осталось в редаксе, то в подавляющем большинстве, народ уезжает на контекст и/или useState и редакса вообще испаряется. ```
Из видео не совсем понятно, как поддерживать данные в актуальном состоянии с беком. Т.е. фронт мог закешировать много данных, часть из которых стала уже неактуальной. Наверное, должен быть способ запросить данные с форсом?
Виталий Черков данные кешируются in-memory, т.е. до первого физического обновления страницы. Также, само собой, есть управление политикой кеширования, в том числе и возможность форса свежих данных
Как лучше описывать схему на бекенде? Кто-то использует обычную строку, кто-то специальные типы GraphQLSchema, а тут файлы .graphql какая-то путаница. В то же время в документации graphql js все пишут просто строкой а у них на гитхабе в readme пример с GraphQLSchema интересно еще как в это все typescript впихнуть))
Но GraphQL не отменяет необходимости валидации даннных на клиенте? Например клиент захотел книгу с полями name author description. А в базе description пустое поле например.
а если данные на сервере поменялись, ну, например, кто-то другой книгу купил и она уже не доступна для остальных пользователей и ее не нужно отображать на юае, то как обновить кэш на фронте?
Интересная технология, но как защитить единственный endpoint через который осуществляется обмен информацией? Я имею ввиду авторизацию. И как разделить права между несколькими пользователями?
Но ведь Redux используют не только для хранения данных из вне, но и для состояния компонентов. К примеру, открыто ли модальное окно. Можно использовать ContextAPI + useReducer, но что по ререндеру в сравнении с Redux?
В 2021 году redux - это уже другой зверь благодаря redux-toolkit. Бойлерплейт почти весь ушел. А еще, там из коробки работает immerjs, так что появились гарантии иммутабельности стейта. Теперь редакс это не только "the most popular oppionated approach to state management" но и просто удобная либа.
А как локальный State хранить?) Я читал доки по local apollo state и там все мягко говоря не очевидно и очень запутано Redux toolkit в принципе решает проблемы с boilerplate Концовка удручает... Вообще складывается впечатление что автор не до конца разобрался с gql, потому что создание того самого прокси который должен сделать за нас грязную работу в виде fetch на ориг api, займёт не так мало времени как может показаться, да и к тому же может заметно замедлить работу самого приложения, а про проблемы с оверхедом, регулировкой глубины и сложности запросов видимо вообще не стоит упоминать.
Про локальный стейт: в apollo можно сохранять данные в его кеш прямо на лету. apollo-link-state - это уже более продвинутая технология, она не всегда нужна. Про создание прокси я говорю так уверенно, потому что и лично занимался этим с нуля, и курировал разработку прокси у других разработчиков, и вместе с php командой по частям внедряли gql в их огромный монолитный проект. Ни в одном из случаев не возникло практически никаких проблем. Главное не писать велосипеды и юзать готовые решения (NestJS, express-graphql, etc).
Пробовали мы использовать graphQL в нашем Symfony проекте - получили замедление ответа сервера на простейшие запросы и проблемы с разграничением прав доступа. В итоге вернулись к REST'у
@@fein7068 Насколько мне известно, они использовали folkloreinc/laravel-graphql и допилили его. Тогда этот модуль еще не был deprecated. Сейчас есть более красивые пакеты, вроде rebing/graphql-laravel.
По поводу оборачивании имеющегося REST API в gql: на грядущем HolyJS будет вот такой доклад, может кому интересно holyjs-piter.ru/2020/spb/talks/26ewxf0eetneqysa49i6sh/
*Короче пацан не отличает стейт менеджер, и кэш данных от бакенда). Редакс нужен чтобы хранить стейт "открыто меню, закрыто меню", "темная тема, светлая тема", "какой пост редактируется, какой отредактированный текст", а парнишка думал что стор нужен чтобы даннные с сервера где-то временно хранить =) короче молодой еще, научится!*
А можно с тобой связаться?Есть один вопрос по коду, весь интернет перерыл.По поводу импорта .graphql, оставь свою телегу, пожалуйста, буду весьма благодарен
Вся работа с сетевыми пайплайнами вынесена в мидлварки ApolloLink. Есть 100500 готовых написанных линков под все случаи жизни, от аутентификации, до очереди запросов и сетевых ретраев. Это, кстати, гораздо лучше с архитектурной точки зрения: все сетевые штуки вынесены по сути на отдельный слой приложения. В то время как в схеме с сагой, это все на уровне редакса по сути.
*Короче пацан не отличает стейт менеджер, и кэш данных от бакенда). Редакс нужен чтобы хранить стейт "открыто меню, закрыто меню", "темная тема, светлая тема", "какой пост редактируется, какой отредактированный текст", а парнишка думал что стор нужен чтобы даннные с сервера где-то временно хранить =) короче молодой еще, научится*
Ну ты кадр) Парнишка не прав, согласен. Но ты тоже не корректно сформулировал. Это единственный источник истины. Единое, общее состояние для приложения, для всех его компонентов. Это же ключевое.
appolo - шляпа. Только react relay. Это лучшее из всего что я перепробовал. А да, redux - не нужен. (p.s осторожно, при чтении документации возможно возгарание очка, нервные срывы, "ну почему, сука, код из примера не работает" и "какого хуя дока не соответствует реальности". Я ПРЕДУПРЕЖДАЛ БЛЕЯТЬ!!!!)
Я ДОПЁР! Я ДО ВСЕГО ДОПЁР!!!!!!
😂😂😂 это прекрасное чувство
Только redux начал использовать , а он уже не нужен
ор
не переживай, редаск еще пару лет нужен будет))
Та он изначально был не нужен )) Я его как заюзал 1 раз, так и прекратил )))
Rudex нужен а GrapfQL используется в связки с несколькими серверами от 2-х и более.
Это его правильное применение.
В остальных случаях используется redux на текущий момент времени.
@@legendarysergeygaming6395 с какими серверами? Зачем GraphQL несколько серверов? В остальных случаях, когда мы не используем Apollo, мы можем пользоваться любым state менеджером: mobx, effector, reatom, recoil
Офигенный материал, классный чистый звук с нужным темпом произношения, крутая подача) Спасибо + лайк и подписка
Оу оу, братишка, с возвращением ! Так, сначала лайк)
Как за этим всем успевать ... Очень информативно , спасибо
Спасибо за видео, второй раз и опять вовремя, сначала про redux (2 года назад) а теперь про gql! Очень понятно объясняешь, респект! Про TS это конечно супер :)
Супер подача, спасибо большое! Только начала смотреть в сторону graphql и сразу получила ответы на все свои вопросы! Подписка))
оо я скучал по тебе дорогой товарищ!
Очень-очень-очень хорошо, настолько приятно слушать было, что я в шоке даже немного. Зарубежный уровень.
Это же гениально! Лучшее объяснение graphQl которое я встречал. Спасибо. А за redux обидно стало, я его только разобрал.
Кайф, сейчас нужно пилить приложение с использованием graphql, я в нем не шарю, но посмотрев видос, захотелось начать им пользоваться)
Это самое понятное и грамотное объяснение что такое GraphQL и в чем его преимущество!
Спасибо большое, вместо тысячи статей)) Го вторую часть про мутации!
Очень круто и полезно! Спасибо!
Спасибо огромное за материал! Супер видео
Шикарное видео, спасибо вам большое)
Божественное объяснение, спасибо!
Очень круто объяснил, спасибо!
Отличный контент, автору лайк за видео!
Очень круто обьясняешь!)
Я посмотрел много видео про GraphQL, и это получилось самым информативным, даже не смотря на то, что является скорее ознакомительным, нежели обучающим
Первая минута - пауза.
Прямо в точку! Именно так и для этого я и пытаюсь использовать Redux!
Браво, наконец-то допер. Жаль что узнал про GraphQl, только сейчас.
Все по делу. Все по существу. Спасибо
Жаль видосов мало,очень трушно объясняет,однопоточно лайк!
Звучит очень заманчиво!
уже середина 21 года, ждем видик, братан)
Отличное видео, спасибо!)
про генерацию типов к тс по схемам тоже крутая тема, можно даже хуки для запросов генерить
По поводу контрактности - придется искать баланс между кол-вом запросов и кол-вом данных в каждом запросе. Под каждый чих не будешь запросы слать. Можно конечно говорить о кешировании, но его тоже придется прогнозировать - что будет закешировано на клиентской стороне, к какому-то моменту, что еще нет. В какой момент кеш будет инвалидироваться.
Блин вот я осёл, когда учил реакт (по книжке) пропустил главу с GraphQL потому что подумал, что это что-то про графику)) Впихнул в своё приложение редакс, уже подобрался к саге и тут твой видос, ну все, буду пробовать graph!
Дмитрий, можете подсказать какую книгу читали? Я тоже учусь, возможно что-то для себя почерпну
@@alexey_horbunov "Реакт быстро" (react quickly) автор Азат Мардан. Но лучше поискать что-то поактуальнее. Например, там нет ни слова про хуки. Описан серверный рендеринг, но без next.js
@@user-mc6ty8zo6y Спасибо огромное)
@@alexey_horbunov незачто)
фу бл. редакс сага, с ужасом вспонимаю времена, когда использовал этот кал. а,да учить это все по книгам не стоит, потому что пока книга пишется и издается, то технология, описанная в ней, устаревает. учитесь по официальной документации
Очень хорошое видео круто обьяснили , можете еще делать видео про мутации?
React-query - как альтернатива apolo client, но еще и работает с rest api, будет интересно послушать твоё мнение :) Спасибо!
еще один вопрос пожалуйста: если в базе данные поменялись после первого вызова, а grapql закэшировал их, то клиент получит устаревшие данные?
Твоя фраза "Привет всем" в начале ролика, тригерит вызов "Привет Сири" на Apple девайсах ))
ночью малеха испугало.
да здравствует, knowcity
А если данные на бэке поменялись, как-то можно сделать повторный запрос, минуя кэш?
Отлично обьясняешь, сидел 2 часа читал документацию, а тут за 20 минут все по полочкам разложил, респект таким пацанам
23:21 надо передать масив, а пишешь обьект. Полагаю все таки заговорился и передать надо было таки обьект, пральна понимаю?
Доброго вам времени суток!... А куда подевались ваши плейлисты на канале?
Здорово, спасибо!
Обязательно ли использовать jsx формат для компонентов graphql ? Почему не используется обычный json формат для объектов?
@knowcity а можешь показать, как это теперь за деплоить на хостинг?
Супер!
огонь!
Сделай пожалуйста пример с Relay и Asp Core 3 Hotchocolate
Интересно, понятно.
А если произошло обновление данных на сервере? То как мы узнаем, что у нас обновилось что-то, если вернется закэшированные старые данные?
видео отличное, все пустые места после статей были заполнены этим видео
Стейт менеджер вообще не используется при использовании GraphQL? Пользуетесь контекстом?
Redux это боль)))) спасибо за видос!!! Ещё с React MobX неплохо заходит
чем боль? супер простой и понятный стейт менеджер
@@draky117 я рад что он для вас легкий и понятный👍
@@brodyagaPATY если вместо GraphQL юзать mobX, легче будет?
Спасибо, шикарное видео. Скрипач не нужен. Только вот там еще ерор возвращаются из этого хука, жаль что не дописали немного компоненты для красоты картины.
Привет!
а новые видосы планируются?)
Класс!
люкс!
ТОП !
Фокус с кешем просто убил))) Вау))
Этот момент конкретно убил редакса.
Вот было сказана что уменьшает время обработки запросов, не совсем понимаю как это. Как в данном случае работают resolve ры GraphQL запросов и как в них должны строятся запросы sql, nosql и чем это отличается от rest-а.
Есть кеш, а как быть если кеш устарел, а в базе уже новые книги - получается сначало придет старье, потом дойдет новое, будет обновление на клиенте.
что будет отабражено если после рендера информация в базе о книге будет изменена? будет ли тригеритсься ререндер?
спасибо за ролик! все работало и было понятно до работы с клиентской частью: в файлах .graphql почему то у меня нет никакой идентификации ни "query" ни всего остального и подобного... все подчеркивает красным... почему так может быть?
Немного не понял на примере с книгами. Точнее, в плане использования GraphQL вместо Redux все ясно. Не ясна принципиальная разница (именно в конкретном примере) между GraphQL и классическими запросами REST API. Что тут мы по заранее запрошенному айдишнику запрашиваем каждую отдельную книгу, что там. В чем профит?
💥 🚀 🙏
тупо лайк
👍
Подскажи а как устроить архитектуру, когда у тебя 10-20 разных таблиц и связей между ними - не в одном же файле graphql это все хранить
Для этого есть GraphQL Federation. Есть пример Нетфликса: th-cam.com/video/QrEOvHdH2Cg/w-d-xo.html
@knowcity Скажите пожалуйста, если мы отказываемся от redux и начинаем вместо него юзать apollo client cache, то как быть с изменениями? Менять данные на прямую в кэше graphql?
Тот же вопрос. На таком Hello world примере легко говорить, что redux не нужен. В большом проекте, где нужно локальное состояние, я не знаю как без redux обойтись
@@valdik630 Получается, что Redux все же остается? =)
@@romuelson нет пока что прорывной альтернативной технологии. Где-то юзают redux, где-то Apollo client, где-то useSWR. Все зависит от масштаба проекта и объема логики на фронте. Мне лично нравится связка Apollo Client/ useSwr для кеширования get запросов и redux toolkit для обработки сложной логики. Кеширование под коробкой хорошо работает ровно до того момента, когда приходится производить сложные мутации данных. Код начинает разрастаться до размеров чистого Redux. И эта проблема, которая толком не решена ещё ни в одной библиотеке полноценно
@@valdik630 Благодарю Вас за ответ, второй день плаваю, в группе телеграмм GraphQL нашел ответ от авторитетного источника:
``` Если у вас redux store только под данные с сервера, то точно переезжайте на аполло клиент. Если в сторе и данные с сервера, и локальные клиентские, то желательно разделить их. И локальные клиентские можно оставить в редаксе. Но там, потом когда смотрят, что осталось в редаксе, то в подавляющем большинстве, народ уезжает на контекст и/или useState и редакса вообще испаряется. ```
Спасибо за видео. =) Жалко джунов, как конвектров юзают их. =)
Зато получат опыт и практику, все довольны )
@@Ivan-bf4ik на комнто етапе рутина может убить желание развиватса. =)
@@disiol1 тут смотря как относится к рутине. Интересные задачи решать хочется всем, но большинство задач, особенно для джунов, это шаблонные задачи.
Это лучшее видео что я видела за всю жизнь по фронтенду, по всем темам вообще ) Это идеально ! Я, наконец, прониклась графкюэлем ! Спасибо !!! 🤍🤍🤍
Из видео не совсем понятно, как поддерживать данные в актуальном состоянии с беком. Т.е. фронт мог закешировать много данных, часть из которых стала уже неактуальной. Наверное, должен быть способ запросить данные с форсом?
Виталий Черков данные кешируются in-memory, т.е. до первого физического обновления страницы. Также, само собой, есть управление политикой кеширования, в том числе и возможность форса свежих данных
Годно, но тема ненужности редукса не раскрыта. Still like tho.
20:30 Где можно узнать поподробнее как использовать generic для usequery?
Andrey Li вот здесь www.apollographql.com/docs/react/development-testing/static-typing/
Спасибо!
Как лучше описывать схему на бекенде? Кто-то использует обычную строку, кто-то специальные типы GraphQLSchema, а тут файлы .graphql какая-то путаница. В то же время в документации graphql js все пишут просто строкой а у них на гитхабе в readme пример с GraphQLSchema интересно еще как в это все typescript впихнуть))
Но GraphQL не отменяет необходимости валидации даннных на клиенте? Например клиент захотел книгу с полями name author description. А в базе description пустое поле например.
Конечно не отменяет
а если данные на сервере поменялись, ну, например, кто-то другой книгу купил и она уже не доступна для остальных пользователей и ее не нужно отображать на юае, то как обновить кэш на фронте?
а, все, внизу увидел ответ на подобный вопрос
Интересная технология, но как защитить единственный endpoint через который осуществляется обмен информацией? Я имею ввиду авторизацию. И как разделить права между несколькими пользователями?
Также как и в reat api. middleware
Норм вещь
Ты че угораешь) я только что посмотрел твои видосы про Redux, а щас я вижу Redux не нужен))))))))
сексуально
Но ведь Redux используют не только для хранения данных из вне, но и для состояния компонентов. К примеру, открыто ли модальное окно. Можно использовать ContextAPI + useReducer, но что по ререндеру в сравнении с Redux?
Ну он хранит данные, но не состояние компонента, за это отвечают хуки
useState для состояния компонентов существует
А где хранить данные собранные на Frontend, например идет сбор данных по экранам, обработка, вычисление и только потом отсылка на сервер????
В стейте роутера
В 2021 году redux - это уже другой зверь благодаря redux-toolkit. Бойлерплейт почти весь ушел. А еще, там из коробки работает immerjs, так что появились гарантии иммутабельности стейта.
Теперь редакс это не только "the most popular oppionated approach to state management" но и просто удобная либа.
20:26 сейчас вообще можно включить автоматическую генерацию кастомных хуков, даже дженерики прописывать не придётся)
А как мидлвари писать? Допустим запрос доступен только авторизованным пользователям
Это же явно сервер сайд фича, нет?)
т.е. если данные на бэке меняются, то graphQL будет всё равно выводить кэш (старые данные), а не актуальные? Сомнительный плюс
Данные на фронте кешируются только до перезагрузки страницы
А как локальный State хранить?)
Я читал доки по local apollo state и там все мягко говоря не очевидно и очень запутано
Redux toolkit в принципе решает проблемы с boilerplate
Концовка удручает...
Вообще складывается впечатление что автор не до конца разобрался с gql, потому что создание того самого прокси который должен сделать за нас грязную работу в виде fetch на ориг api, займёт не так мало времени как может показаться, да и к тому же может заметно замедлить работу самого приложения, а про проблемы с оверхедом, регулировкой глубины и сложности запросов видимо вообще не стоит упоминать.
Про локальный стейт: в apollo можно сохранять данные в его кеш прямо на лету. apollo-link-state - это уже более продвинутая технология, она не всегда нужна.
Про создание прокси я говорю так уверенно, потому что и лично занимался этим с нуля, и курировал разработку прокси у других разработчиков, и вместе с php командой по частям внедряли gql в их огромный монолитный проект. Ни в одном из случаев не возникло практически никаких проблем. Главное не писать велосипеды и юзать готовые решения (NestJS, express-graphql, etc).
В любом из описанных сценариев: разработка gql прокси настолько упрощает разработку интерфейсов, что все затраченные силы окупаются сполна.
Пробовали мы использовать graphQL в нашем Symfony проекте - получили замедление ответа сервера на простейшие запросы и проблемы с разграничением прав доступа. В итоге вернулись к REST'у
В php либах для graphql есть косяки. Ребята у нас в компании допиливали библиотеки руками, стало норм) А с права доступа какие проблемы?
@@ecroFeGushKa А долго допиливали?
@@fein7068 Насколько мне известно, они использовали folkloreinc/laravel-graphql и допилили его. Тогда этот модуль еще не был deprecated. Сейчас есть более красивые пакеты, вроде rebing/graphql-laravel.
@@ecroFeGushKa спасибо!
По поводу оборачивании имеющегося REST API в gql: на грядущем HolyJS будет вот такой доклад, может кому интересно holyjs-piter.ru/2020/spb/talks/26ewxf0eetneqysa49i6sh/
th-cam.com/video/RDBEfvZT1yQ/w-d-xo.html
недавно запостили наконец-то
*Короче пацан не отличает стейт менеджер, и кэш данных от бакенда). Редакс нужен чтобы хранить стейт "открыто меню, закрыто меню", "темная тема, светлая тема", "какой пост редактируется, какой отредактированный текст", а парнишка думал что стор нужен чтобы даннные с сервера где-то временно хранить =) короче молодой еще, научится!*
А можно с тобой связаться?Есть один вопрос по коду, весь интернет перерыл.По поводу импорта .graphql, оставь свою телегу, пожалуйста, буду весьма благодарен
В любом случае везде требуют знание редакса
братан аxуенно делаеш контент сними продолжение по поводу
резолверов ,кeширования ...
Каким образом на клиенте работает автозаполнение по полям, которые указаны на сервере? Каким образом клиент вообще знает какие поля существуют??
Мне чудится или на этом канале раньше было больше видео?
Окей редакс вам не нужен, а сагу вы как замените?) Каждый раз писать локальные костыли для к примеру предотвращения повторных запросов?)
Вся работа с сетевыми пайплайнами вынесена в мидлварки ApolloLink. Есть 100500 готовых написанных линков под все случаи жизни, от аутентификации, до очереди запросов и сетевых ретраев.
Это, кстати, гораздо лучше с архитектурной точки зрения: все сетевые штуки вынесены по сути на отдельный слой приложения. В то время как в схеме с сагой, это все на уровне редакса по сути.
Я смотрел это видео с надеждой что покажут как работать с мутацией...
eeeeebaaaa vot ono kak
ты понимаешь что у тебя меньше просмотров с микро текстом ? найми чела какого нибудь, может он текст увеличит, напиши на биржу фриланса задачу такую
+
Так теперь фронты должны еще и на пол шишечки в бэкенд :)
Эх, а раньше хтмл+цсс+жквери и все....
Хорошие фронты и раньше должны были быть на пол шишки в бекенде)
*Короче пацан не отличает стейт менеджер, и кэш данных от бакенда). Редакс нужен чтобы хранить стейт "открыто меню, закрыто меню", "темная тема, светлая тема", "какой пост редактируется, какой отредактированный текст", а парнишка думал что стор нужен чтобы даннные с сервера где-то временно хранить =) короче молодой еще, научится*
Ну ты кадр) Парнишка не прав, согласен. Но ты тоже не корректно сформулировал. Это единственный источник истины. Единое, общее состояние для приложения, для всех его компонентов. Это же ключевое.
Ура, правильное видео!! Наконец. А то редакс, саги, бла бла бла
appolo - шляпа. Только react relay. Это лучшее из всего что я перепробовал. А да, redux - не нужен. (p.s осторожно, при чтении документации возможно возгарание очка, нервные срывы, "ну почему, сука, код из примера не работает" и "какого хуя дока не соответствует реальности". Я ПРЕДУПРЕЖДАЛ БЛЕЯТЬ!!!!)
Может давно аполло не трогал? Версия 3.0 и старые версии аполло - это как жопа и палец
redux suck? это что-то новенькое 0:52