[Feature Request] API for UI plugins

[danielo515]

As far as I know, there is no way to extend the current ui using plugins. It will be nice if you add some

[taylorgoolsby]

I would like this because it brings insomnia a step closer to being able to emulate this with plugins: https://learning.getpostman.com/docs/postman/scripts/intro_to_scripts/

[gschier]

Just to provide a bit of insight here. UI plugins are definitely something that I want to implement eventually. Now that Insomnia is stable, the general goal is to go over the current features 1-by-1 and extend the plugin system so that each can be refactored into plugins.

So, this means authentication, request body editors, response viewers, menu items, etc will hopefully all be possible to extend via the plugin API in the future. I don't have any set roadmaps for this yet but that's the idea

[danielo515]

Wow, that sounds more like a full-fledged platform for any application that could need network request and not just a request runner 🤣

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[danielo515]

Dear stale bot,you are a rude person that does not bring anything useful to the conversation. This is a planned feature for whenever the developers find a slot to implement it.

[gschier]

There, @stale won't close it now with that tag attached 😄

[gschier]

I'd love to hear some ideas that people have for UI plugins! 💯

This is a simple example, but the latest release came with the ability for plugins to add entries to the folder dropdown menu: https://support.insomnia.rest/article/26-plugins#folder-actions

UI features like this are nice because they don't require the ability to define UI via HTML. Everything can be done with configuration objects in JS.

The test runner suggested here is slightly more complicated because it would require the plugin author to have the ability to create a new tab and place a code editor component inside of it.

[danielo515]

Adding entries to a drop-down is definitively a good step forward. However, I think that the real power comes in the form of being able to define "views". Not sure if they should be inside a tab, a panel, a popup or even any of those. Have you thought about mimic the model that chrome has for extensions? seems to be successful

[gschier]

I think the Chrome model could work but it'd be nice if plugins could have access to the native Insomnia components in order for plugins to provide a nice experience. For example, you'd have to use the Insomnia code editor and input fields to get the autocomplete.

[trizz]

It would be great if it is possible that a plugin can add another panel (or tab) with an URL or HTML view. Currently I'm constantly cmd+tabbing between Insomnia and my debug page in a browser (Laravel Telescope in my case) to view what happens when I fire a request.

It would be very nice if I can create a plugin that loads the (external) debug info of my request in a panel/tab within Insomnia itself.

To take things a step further, if the URL that will be loaded can contain data based on the response, it is possible to directly navigate to a specific request, for example if the response headers have a 'request-id' header, a panel/tab can be loaded with 'http://my-debug.info/view/:request-id'.

[danielo515]

what you are proposing @trizz seems a bit different but much simpler that UI plugins.

[trizz]

@danielo515 You are absolutely right, but as I see it, it can be a start to fully fledged UI plugins. I can imagine other plugins that want to display a webview based on stuff of the request/response.

[danielo515]

Yes, I'm not saying that it has no value, I'm just saying that, despite being a good idea, it is way easier and simpler (I think) to implement. So maybe opening a new issue, and relating it to this one it could get implemented faster. But, this is something that has to be decided by @gschier , not me, I am just suggesting.

[sergiopacezup]

May I suggest a simple (AFAICT) first step. Allow plugins to add a free text tab on the requests and pass the user typed content (perhaps tag processed) back to the plugin. This would allow plugin developers to start gathering UI "usecases" and, based on those, discuss specific components APIs.

[theFlyingCat04]

Two ideas for UI-plugins to customize the response view:

• one could integrate jq to analyze the response in a more detailed way than just with JSON-Paths or just trying to figure out by hand, especially for large responses
• in my opinion yaml is easier to read than json in most cases. so a plugin could be implemented to change the response from json to yaml and vice versa with a simple button

[Dunky13]

My idea for a UI plugin would be an environment editor. I want to use the variables, but I need to test with different values. I want to be able to edit the base environment or even sub environments in a textfield. So I don't have to click to open & edit as much.

I use this because I want to chain two requests in following sequence

• /run/\<num>
• /run/\<num>/log/\<id>

Where the first endpoint needs to be run first. as it returns the If I want to test with a different num, I have to change either both endpoints (hardcoded num), or change environment variable.

[aesyondu]

My usecase is I wanted to add a Full Timeline Tab in the response-pane, which would display the full timeline of the request (request header & body, response header & body). Maybe add a copy to clipboard somewhere. Also add a Send and Download Full Timeline in the Send context menu.

[codeasashu]

I've tried my hands on adding tabs to request window for my usecase (see #2580). A basic attempt seems to be doing for me. However, rendering tabs for all requests initially, while having some heavy IO bound operations might lead to crashes, hence will be planning to async these.

Here is the PR implementing the same

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.