Default Serializer should fallback to JSON when requests are initiated from the browser?

[dylanhitt]

Right now when making a request using fuego 0.14.0 from the browser to an json endpoint we get a 500 error:

I would expect fuego to infer that I'm hitting a json endpoint in some capacity. I have a few thoughts on this

1. Infer this on route creation as we know the return types and which one we accept as proper html.
2. Attempt a fallback to sendJson when text/html after all the attempts to render something in SendHTML. We'd be able to simple call SendJSON at the end of the function.
3. Or we perform some type of check in HTTPHandler, but I'm pretty sure we'd run into odd cases here when a caller would want to use their own custom serializer.

This discussion also assume SendError is at play here too.

Cheers

[EwenQuim]

Yeah that something i noticed, but since the browser sends an Accept: text/html that's kind of weird. To be more precise, the browser will send something like Accept: text/html,text/xhtml,blablabla,*/*. We should maybe just iterate over the accepted content-types and if */* is found, accept to return the inferred type ?

[dylanhitt]

By “accept to return the inferred type” do you mean we just attempt to return JSON or try to return anything that we can?

[EwenQuim]

I meant JSON by default and HTML if the type implements fuego.CtxRenderer (Render(context.Context, io.Writer)) interface

[dylanhitt]

Got it. Expect a PR soon 😄

[dylanhitt]

Side thought: should we square up all of our SendJson, SendYaml ... function variables to match the signature for WithSerializer? The same idea for WithErrorSerializer? I'm currently having to wrap it, but I think we should make them easily pluggable for our users.

[EwenQuim]

Yes I think we should, indeed this is a good idea

[EwenQuim]

This is a breaking change but this is niche enough to do it, I think that's OK