Песочница

Blog by Fi1osof

Нужна консультация

Не работает JS что делать ?

Переход по новому меню в админке

Загрузка файлов через migx

Улучшенный поиск на сайте Клуба

MODX-Клуб превращается в фриланс-биржу

Собственное портфолио на сайте MODX-Клуба

Улучшенный каталог сайтов

Эксперимент. Корзина для minishop2 на реакте.

React-js. Урок №2. Запросы с помощью GraphQL

Наконец-то дождался обновления интерфейса в сбербанк-онлайн для юриков. Весьма неплохо и юзабельно получилось. И как вы думаете на чем сделано? На реакте))

Наконец-то дождался обновления интерфейса в сберба

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

Вадим, почти все это есть здесь (карты есть на дру

Здорово, давно ждал этого функционала

Действительно здорово.  Несколько дней, а столько новшеств. То ли еще будет :)

Действительно здорово.  Несколько дней, а столько новшеств. То ли еще будет :) В предвкушении...

Действительно здорово.  Несколько дней, а столько 

Это всё сила React

Николай, это очень крутой функционал! Ждем уроков по react+modx!

Николай, это очень крутой функционал! Ждем уроков 

Такой вопрос... Насколько я знаю, у вас react работает с процессорами getdata и т.д. Насколько целесообразной была бы интеграция restful api? 

Такой вопрос... Насколько я знаю, у вас react рабо

Честно сказать, я не очень понимаю что такое RESTful. Прочитал в вики, но все равно не нашел четких критериев что есть что. Но судя по всему, здесь именно так и используется. Интерфейсы-то изоморфные. MODX здесь является по сути сервером, никак не влияющим на отрисовку HTML. Он только отдает данные в JSON. Даже на стороне сервера, там крутится node.js, а Реакт-приложения получаются данные в JSON.

Честно сказать, я не очень понимаю что такое RESTf

Рад бы обратную связь дать, но работы добавлял не лично, всех нюансов не видел :)

Рад бы обратную связь дать, но работы добавлял не 

Ну, теперь они у тебя в профиле есть)

Осталось только добавить пакеты в репо :)

К слову: сделай отправку комментария по Ctrl+Enter.

Осталось только добавить пакеты в репо :) К слову: сделай отправку комментария по Ctrl+Enter.

Осталось только добавить пакеты в репо :) К слову:

Добавил Ctrl+Enter

Сайт улучшается прямо на глазах )

Вы еще не все видите :) Там под капотом столько всего делается... Прям реально очень много. Сейчас вот еще раздел Комментарии появится (хотя меню итак уже заметно выросло). Сейчас вот еще виртуализацию DOM на стороне сервера победил, и теперь вообще все рендерится на сервере, то есть JS в браузере можно отключить и почти не заметить разницы. Поисковики будут в восторге! :)

Вы еще не все видите :) Там под капотом столько вс

Не забывай в процессе статьи писать, а то начало было многообещающим. Ждем продолжения! ;)

Не забывай в процессе статьи писать, а то начало б

Блин, я скоро спать перестану)) Времени нет на это удовольствие) И на улицу ходить перестану. 

Но ничего, скоро скорректирую график и начну писать свежие уроки.

Блин, я скоро спать перестану)) Времени нет на это удовольствие) И на улицу ходить перестану. Но ничего, скоро скорректирую график и начну писать свежие уроки.

Блин, я скоро спать перестану)) Времени нет на это

Звучит радостно! Набираемся терпения и ждем ))

На самом деле, на первый взгляд реакт действительно кажется слишком перенавороченным (зачем рисовать html через js?!), но когда начинаешь решать задачи чуть сложнее отправки формы обратной связи, понимаешь, что это сильно упрощает жизнь. И даже и с такой формой программирование валидации упрощается в разы.

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

Сложно конечно решать задачи такого рода без вебпака....но я я все же попробую предложить свои мысли по этому поводу снова: а стоит ли отказываться от него вообще? от вебпака? Что мешает нам делать все в "правильном" виде? мне видится все же один базовый компонент реакта(ядро) и много асинхронных модулей к нему, которые подгружаться будут динамично - лучший вариант....базовый компонент(ядро) работает с бэкендом(modx), загружает к примеру список модулей, его зависимостей, чанки(шаблоны), а также обеспечивает взаимодействие модулей с бэкендом(процессором modx)....получается все наши маленькие модули, будь то для вывода корзины или постов, будут "тупыми" и будут взаимодействовать только с ядром(основным модулем реакта)....я уверен что такой подход изначально избавит от множества головняка в будущем. И возможностей при таком подходе может быть больше: к примеру модуль для вывода целиком страницы, модуль для авторизации, модуль для модальных окон....к тому же позволил бы избавиться от множества jquery кода

Сложно конечно решать задачи такого рода без вебпа

Тут ставка делалась на простоту установки в MODX. А так - я тоже согласен, с webpack гораздо гораздее получается

Тут ставка делалась на простоту установки в MODX. 

Роман, без server-side rendering это все будет совсем не то, многим это по SEO ударит.  А если на стороне сервера еще средствами MODX прорисовывать, то будет задвоение шаблонизации и двойная нагрузка. Это все только усложнит проект. В общем пока нет ни в чем уверенности. Время покажет.

Роман, без server-side rendering это все будет сов

Действительно очень нужный инструмент. Позволяет навести порядок в запросах к серверу

Действительно очень нужный инструмент. Позволяет н

мне понравилось, поюзал :D правда практического применения пока не было, но уже преставляю где можно использовать

мне понравилось, поюзал :D правда практического пр

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

Когда по отдельности берешь эти данные, тогда еще ничего. А когда надо, к примеру, такое получить:

   По каждому пользователю список его работ

       В каждой работе получить список участников работы

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

                По каждому направлению получить сколько всего работ по данному направлению есть

                Сколько компаний работает по данному направлению

Уровней вложенности может быть очень много. И каждому может понадобиться свой набор данных. Попробуй-ка на классических технологиях такое реализовать (конструктор запросов). 

На простых сайтах, конечно, это решение скорее всего будет избыточным. Но на сайтах покрупнее очень даже нужная штука. Вот смотри структура данных здесь (далеко не полная): Пользователь Команда Работа портфолио Вид деятельности Топик Комментарий Когда по отдельности берешь эти данные, тогда еще ничего. А когда надо, к примеру, такое получить: Список пользователей По каждому пользователю список его работ В каждой работе получить список участников работы По каждому участнику получить список направлений, по которым он участвовал в проекте По каждому направлению получить сколько всего работ по данному направлению есть Сколько компаний работает по данному направлению и т.д. и т.п. Уровней вложенности может быть очень много. И каждому может понадобиться свой набор данных. Попробуй-ка на классических технологиях такое реализовать (конструктор запросов).

На простых сайтах, конечно, это решение скорее все

Все решено)

Что не так было? Просто домен не прописали в гугл.картах, или ключ не указали?

Что не так было? Просто домен не прописали в гугл.

Не прописал путь к css и ключ забыл сменить)

Николай, большое спасибо за уроки! Намереваюсь попробовать Vulcan.js

Николай, большое спасибо за уроки! Намереваюсь поп

ОК. Как будут результаты, если что, напишите небольшой топик что и как там работает, плиз. 

А я свой один проект переделываю, полностью на JS. Очень интересные техники новые освоил, и в GraphQL продвинулся. Скоро новые уроки появятся.

ОК. Как будут результаты, если что, напишите небольшой топик что и как там работает, плиз. А я свой один проект переделываю, полностью на JS. Очень интересные техники новые освоил, и в GraphQL продвинулся. Скоро новые уроки появятся.

ОК. Как будут результаты, если что, напишите небол

Прошу прощения, удалось найти информацию. теперь другие вопросы посыпались, но сначала сам попробую)

Прошу прощения, удалось найти информацию. теперь д

*file - это значение именно текущего документа (его TV-поля в целом). А +file - это переменная-плейсхолдер внутри обработки ТВ-поля, то есть более локальная переменная. Опубликуйте текстовое значение из базы данных вашего ТВ-поля и ссылку на HTML-документ, которую вы получаете при обработке ТВ-поля. 

И почитайте топики здесь: https://modxclub.ru/topics/?query=inputTV 

Там просто есть статьи, в которых рассматривается более тонкая настройка миги. Там есть разница между тем, когда указываешь свойство поля как тип файла, и когда создаешь отдельную ТВшку с типом файл и указываешь ее для MIGX-твшки.

*file - это значение именно текущего документа (его TV-поля в целом). А +file - это переменная-плейсхолдер внутри обработки ТВ-поля, то есть более локальная переменная. Опубликуйте текстовое значение из базы данных вашего ТВ-поля и ссылку на HTML-документ, которую вы получаете при обработке ТВ-поля. И почитайте топики здесь: https://modxclub.ru/topics/?query=inputTV Там просто есть статьи, в которых рассматривается более тонкая настройка миги. Там есть разница между тем, когда указываешь свойство поля как тип файла, и когда создаешь отдельную ТВшку с типом файл и указываешь ее для MIGX-твшки.

*file - это значение именно текущего документа (ег

Николай, вижу мой совет про graphql в первом уроке был принят ))). Благодарю за этот урок, Вы занимаетесь хорошим делом! Хотел бы добавить в преимущества:

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

2. Возможность работать сразу с несколькими источниками данных. Поскольку по сути graphql это агрегатор, мы можем накрутить работу сразу с несколькими базами и соединять данные в одну выборку.

3. Быстро разворачивается в сравнении с рест. Если написать генератор для моделей, вообще за 5 минут. И за счёт того, что всего 1 эндпоинт мы получаем полнофункциональный вариант по сути, только связи руками накрутить. Ну исключение с мутациями, на них генератор не сделать.

Николай, вижу мой совет про graphql в первом уроке был принят ))). Благодарю за этот урок, Вы занимаетесь хорошим делом! Хотел бы добавить в преимущества: 1. Структура ответа всегда точно повторяет структуру запроса, все сталкивались с проблемой когда в ресте поменялась структура объекта  в ответе и все ломалось. И версионность больше не нужна по этой причине. 2. Возможность работать сразу с несколькими источниками данных. Поскольку по сути graphql это агрегатор, мы можем накрутить работу сразу с несколькими базами и соединять данные в одну выборку. 3. Быстро разворачивается в сравнении с рест. Если написать генератор для моделей, вообще за 5 минут. И за счёт того, что всего 1 эндпоинт мы получаем полнофункциональный вариант по сути, только связи руками накрутить. Ну исключение с мутациями, на них генератор не сделать.

Николай, вижу мой совет про graphql в первом уроке

Да, Артем, сейчас граф - один из моих основных инструментов и ввел я его уже на нескольких проектах. Очень круто он себя показывает при внедрении на уже готовые проекты. К примеру, не так давно я анонсировал запуск проекта http://troika-gorod.ru/ , который написан полностью на JS, а MODX используется только для проброса и модификации API-запросов. И вот они обратились за доработками, и я решил, что раз функционал растет, то имеет смысл граф ввести, чтобы потом не было мучительно больно. Отмечу, что ввести граф, на самом деле - это совсем не 5 минут (если сайт - не сайт-визитка), во всяком случае у меня. Я руками все пишу. По моим наблюдениям, на среднем проекте только листинг основных запросов составляет строк 500, и это еще при условии использования фрагментов, которые вставлять можно в разные части. На тройке - это 1000 строк. Все это - три десятка АПИ-запросов. http://joxi.ru/bmoY6bGSMdRzpA 

Так вот, здесь себя граф показывает не только как отличное средство для построения запроса, но и как архитектор АПИ. Вот пара примеров с этой тройкой: 

Справа - это предоставленная документация. Видно, что вкралась опечатка.

А вот пример, почему такое невозможно с графом: 

А вот наглядный пример, для чего это делается: вот я одним запросом получаю сразу три блока информации http://joxi.ru/bmoY6bGSMdRJpA 

При чем в своем конечном ответе я получаю именно один конечный многоуровневый JSON. А то, что граф выполнил для сбора этой информации три запроса - так это как раз и демонстрирует то, о чем говорит Артем - возможность работать сразу с несколькими источниками данных. Здесь три запроса выполняется только потому, что на стороне сервера не работает граф и он просто не может вернуть данные одним ответом. А вот на другом моем проекте (и не только на нем), граф крутится и на сервере и в ответе в одном я получаю все нужные мне данные 

Кстати, в связке с сервером, у меня получилась вообще очень интересная связка: у меня и на сервере, и на клиенте используется единая схема. Это позволяет, во-первых, на сервер в запросе слать не портянку, а просто название операции с параметрами. К примеру, на получение этих данных отправляется вот такой запрос:

А во-вторых, я эту же модель, просто с другими обработчиками, использую и на стороне клиента. То есть когда у меня данные подгружены в браузер в хранилища, я могу выполнять структурированные запросы прям в браузере. К примеру, вот так я получаю в браузере данные для карты, со всеми нужными вложенностями, и совершенно без обращения к серверу

Короче, про него можно очень много всего рассказывать. И надо отметить, что работа с ним - это не всегда праздник. В том же браузере, из-за того, что он использует промисы, он не рассчитан на множественный вызов (то есть когда во внутренних резолверах выполняешь еще запросы на граф). В случае сотен вызовов в рамках одного запроса, выборка конечная может составить 10 секунд и более :) Но если правильно оптимизировать все, то этот же объем данных будет получен менее чем за секунду.

Да, Артем, сейчас граф - один из моих основных инструментов и ввел я его уже на нескольких проектах. Очень круто он себя показывает при внедрении на уже готовые проекты. К примеру, не так давно я анонсировал запуск проекта http://troika-gorod.ru/ , который написан полностью на JS, а MODX используется только для проброса и модификации API-запросов. И вот они обратились за доработками, и я решил, что раз функционал растет, то имеет смысл граф ввести, чтобы потом не было мучительно больно. Отмечу, что ввести граф, на самом деле - это совсем не 5 минут (если сайт - не сайт-визитка), во всяком случае у меня. Я руками все пишу. По моим наблюдениям, на среднем проекте только листинг основных запросов составляет строк 500, и это еще при условии использования фрагментов, которые вставлять можно в разные части. На тройке - это 1000 строк. Все это - три десятка АПИ-запросов. http://joxi.ru/bmoY6bGSMdRzpA Так вот, здесь себя граф показывает не только как отличное средство для построения запроса, но и как архитектор АПИ. Вот пара примеров с этой тройкой: Справа - это предоставленная документация. Видно, что вкралась опечатка. А вот еще: А вот пример, почему такое невозможно с графом: А вот наглядный пример, для чего это делается: вот я одним запросом получаю сразу три блока информации http://joxi.ru/bmoY6bGSMdRJpA При чем в своем конечном ответе я получаю именно один конечный многоуровневый JSON. А то, что граф выполнил для сбора этой информации три запроса - так это как раз и демонстрирует то, о чем говорит Артем - возможность работать сразу с несколькими источниками данных. Здесь три запроса выполняется только потому, что на стороне сервера не работает граф и он просто не может вернуть данные одним ответом. А вот на другом моем проекте (и не только на нем), граф крутится и на сервере и в ответе в одном я получаю все нужные мне данные Кстати, в связке с сервером, у меня получилась вообще очень интересная связка: у меня и на сервере, и на клиенте используется единая схема. Это позволяет, во-первых, на сервер в запросе слать не портянку, а просто название операции с параметрами. К примеру, на получение этих данных отправляется вот такой запрос: А во-вторых, я эту же модель, просто с другими обработчиками, использую и на стороне клиента. То есть когда у меня данные подгружены в браузер в хранилища, я могу выполнять структурированные запросы прям в браузере. К примеру, вот так я получаю в браузере данные для карты, со всеми нужными вложенностями, и совершенно без обращения к серверу Короче, про него можно очень много всего рассказывать. И надо отметить, что работа с ним - это не всегда праздник. В том же браузере, из-за того, что он использует промисы, он не рассчитан на множественный вызов (то есть когда во внутренних резолверах выполняешь еще запросы на граф). В случае сотен вызовов в рамках одного запроса, выборка конечная может составить 10 секунд и более :) Но если правильно оптимизировать все, то этот же объем данных будет получен менее чем за секунду.

Да, Артем, сейчас граф - один из моих основных инс

Николай, да тут смысл в том, чтобы одним запросом к серверу получать сразу все данные. Кстати этот момент хорошо работает и в случае с серверным рендерингом. Мы любые данные можем получить одним запросом и не нужно ничего комбинировать или слать несколько. Поскольку серверный рендеринг работает синхронно это огромное преимущество. Во первых мы не перегружаем локальный сокет петлями, во вторых один запрос (который распараллелить внутри GraphQL) выполняется значительно быстрей, что напримую влияет на первую выдачу HTML в браузер

С ошибками Вы точно подметили, один из значимых плюсов!. Стоит тоже в статью добавить )). Примеры отличные !)

Николай, да тут смысл в том, чтобы одним запросом к серверу получать сразу все данные. Кстати этот момент хорошо работает и в случае с серверным рендерингом. Мы любые данные можем получить одним запросом и не нужно ничего комбинировать или слать несколько. Поскольку серверный рендеринг работает синхронно это огромное преимущество. Во первых мы не перегружаем локальный сокет петлями, во вторых один запрос (который распараллелить внутри GraphQL) выполняется значительно быстрей, что напримую влияет на первую выдачу HTML в браузер С ошибками Вы точно подметили, один из значимых плюсов!. Стоит тоже в статью добавить )). Примеры отличные !)

Николай, да тут смысл в том, чтобы одним запросом 

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