Комментарии 11
НЛО прилетело и опубликовало эту надпись здесь
Network в devtools удобен для REST. Можно фильтровать по эндпоинту, что является фильтацией по сущности и как бы подразумевает фильтрацию по методу. Хотя, не знаю даже, можно ли фильтровать по типу HTTP метода? По коду ошибки? Не пробовал.
Но в любом случае, в JSON-RPC для этого нужно парсить тело запроса и тело ответа. А значит, нужно расширение.
А вот фильтры к нему я планирую докрутить попозже.
Да, разумеется, данные по метке времени и инициализатору запроса есть в HAR, так что можно вытащить и показать.
Меня больше смущает то, что в текущей реализации, расширение ловит данные по факту завершения запроса. Т.е. пока запрос в pending, в Network он уже есть, а в расширении ещё нет.
Но это тоже так или иначе можно попробовать решить.
Но в любом случае, в JSON-RPC для этого нужно парсить тело запроса и тело ответа. А значит, нужно расширение.
А вот фильтры к нему я планирую докрутить попозже.
Да, разумеется, данные по метке времени и инициализатору запроса есть в HAR, так что можно вытащить и показать.
Меня больше смущает то, что в текущей реализации, расширение ловит данные по факту завершения запроса. Т.е. пока запрос в pending, в Network он уже есть, а в расширении ещё нет.
Но это тоже так или иначе можно попробовать решить.
НЛО прилетело и опубликовало эту надпись здесь
Отлично Network умеет фильтровать и по методу и по статус коду. Если вбить в поле фильтр
method:GET -status-code:200, получим все get методы со статусом не 200. Лучше всего туда — начать вбивать и он подскажет все возможные варианты.
method:GET -status-code:200, получим все get методы со статусом не 200. Лучше всего туда — начать вбивать и он подскажет все возможные варианты.
Ну, это хорошо, спасибо, буду знать.
Действительно, овердохрена способов:
developers.google.com/web/tools/chrome-devtools/network/reference#filter
Но это для REST, не для JSON-RPC.
Это могло бы быть достижимым, будь фильтрация регулярниками по телу запроса/ответа. Но этого нет, да и было бы тем ещё извращением.
Действительно, овердохрена способов:
developers.google.com/web/tools/chrome-devtools/network/reference#filter
Но это для REST, не для JSON-RPC.
Это могло бы быть достижимым, будь фильтрация регулярниками по телу запроса/ответа. Но этого нет, да и было бы тем ещё извращением.
Катастрофически не хватает картинок. Ваше приложение называется JSON-RPC Viewer, а это значит, что основное его назначение — просмотр. Вы бы картники какие-то в статью вставили, чтобы понять, что оно делает. Пройдя по ссылкам, все что удалось увидеть — это карнинка с низким разрешением в Chrome Store из которой что-то понятно, но немногое. Например, как ваш просмотрщик ведет себя на сложных объектах и массивах.
Ну, ваша правда. Снабдил эту статью скриншотом, тем же что в сторе, но без сжатия.
Однако замечу, что ваш интерес это изображение всё равно не удовлетворит, поскольку объекты там как раз «простые», что в params, что в error.
Но, я не уделил этому много внимания, потому что и не писал свой визуализатор json-дерева, а пользовался пакетом www.npmjs.com/package/json-formatter-js
Его демка у автора: azimi.me/json-formatter-js
Как ведёт. Ну, обычно, полноценное дерево. Да, наверное может и обгадиться на слишком большом JSON, ну так и сам фронтенд может точно так же на нём спотыкаться.
Однако замечу, что ваш интерес это изображение всё равно не удовлетворит, поскольку объекты там как раз «простые», что в params, что в error.
Но, я не уделил этому много внимания, потому что и не писал свой визуализатор json-дерева, а пользовался пакетом www.npmjs.com/package/json-formatter-js
Его демка у автора: azimi.me/json-formatter-js
Как ведёт. Ну, обычно, полноценное дерево. Да, наверное может и обгадиться на слишком большом JSON, ну так и сам фронтенд может точно так же на нём спотыкаться.
Нет поддержки просмотра batch запросов jsonrpc 2.0.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Больше удобств адептам JSON-RPC