"Open in new tab" for new HTTP handler only respects route after a page refresh

[StachuDotNet]

• create an HTTP handler with route /route
• go to "open in new tab"

The browser should direct to the equivalent BWD URL with the /route added, but it currently directs to the root of the BWD URL.

This feature works as intended after a refresh of the page, though.

[pbiggar]

There's a bit of a tricky question around "open a new tab", which is should they respect the request as it was made, or the request now. For example, if the path changed, we should clearly call the new URL. But it's not always possible to adapt the whole thing for the new thing.

That's just a bit of context, as this code is a bit of a mess, and this is (partly) why. I fully support all fixes of this code: you'll discover it has quite a lot of other problems too.

[StachuDotNet]

I'm not sure I understand.

Describing an example where it's "not [...] possible to adapt the whole thing for the new thing" might help?

[pbiggar]

For example if the request was made to a path with no variables (such as /hello), but then we added variables to it (such as /hello/:user).

[StachuDotNet]

I appreciate that context - agreed, that's a tricky question, and I'm not sure what's "right."
When I get to this, I think I'll start off with exploring and tidying the relevant code, and hope that the 'right' answer comes to mind while working in that space, after playing with some ideas.

[pbiggar]

Also, there's the same or very similar challenge with "copy as curl"

[pbiggar]

Coming up with clear rules for both would be a great step forward, as would documenting those rules.

[StachuDotNet]

copy-as-curl is based on the current trace, correct? If so, I think it'd be best to be re-branded as "copy trace as curl," and the trace should have everything it needs to produce the curl command. (in fact, the cURL command could be generated by a stdlib function, if Trace is a public type - handwavey a bit, but I think the idea is clear enough.) For GET handlers/traces specifically, an "open in new tab" should be rebranded to "open trace in new tab," again getting all context from the trace.
Short of a stdlib function (which is a stretch), an endpoint in dark-editor of GET /curl-for-trace would get the job done.
This is all a bit messy with huge request bodies, though - not sure what to do with that.

Maybe all of that UI should exist when you hover on the trace icon on the left, rather than where it exists today.

---

Separately, I'd like a feature separate from a specific trace:

• for all handlers, provide a place for the user to input relevant info (e.g. URL params, request body)
• given that configuration is complete,
  • for all handlers, provide a 'copy as curl' option
  • for GET handlers specifically, provide a 'open in new tab' option that's just the URL bit of the cURL command
    (I suppose this is assuming GET handlers that don't use a body...)

Thinking now, this feels like a tiny version of Postman's UI.

---

What do you think?

[pbiggar]

copy-as-curl is based on the current trace, correct? If so, I think it'd be best to be re-branded as "copy trace as curl," and the trace should have everything it needs to produce the curl command

I like this. But also, the purpose of the curl command is to replay it, so if the handler has changed in someway, this does need to be reflected (e.g. the path is changed).

For GET handlers/traces specifically, an "open in new tab" should be rebranded to "open trace in new tab," again getting all context from the trace.

This sound good.

Short of a stdlib function (which is a stretch), an endpoint in dark-editor of GET /curl-for-trace would get the job done.
This is all a bit messy with huge request bodies, though - not sure what to do with that.

I'm guessing you're thinking "rewrite in Dark" - we can port refactoring functions to dark at some point, but this issue is more about the behaviour, right?

Maybe
Separately

Can you open new issues for these?

[StachuDotNet]

I'm guessing you're thinking "rewrite in Dark" - we can port refactoring functions to dark at some point, but this issue is more about the behaviour, right?

Yes, you're right - I was thinking "rewrite in Dark," and that's a bit out of scope here.

copy-as-curl is based on the current trace, correct? If so, I think it'd be best to be re-branded as "copy trace as curl," and the trace should have everything it needs to produce the curl command

I like this. But also, the purpose of the curl command is to replay it, so if the handler has changed in someway, this does need to be reflected (e.g. the path is changed).

That's fair - I think a next step here is to outline all possible classes of change to an HTTP handler, and determining which of them we can adjust the request for, appropriately:

e.g. HTTP method changed -> we can easily produce a cURL to match.

(I haven't gone through and listed the possible classes of change - we can follow up with that the next time someone visits this)