`new Response('message', { status: 404 })` should auto-translate to `set.status`

[asilvas]

The docs aren't super clear on this subject, but I see no reason the formal Bun format could not auto translate.

Basically in addition to the current pattern, it would be very desirable to also support new Response:

// TODAY
app.get('/test', ({ set }) => {
  if (somethingBad) {
    set.status = 404;
    return "that doesn't exist";
  }

  return 'yay';
});

Would be great if this worked as well!

// NEXT
app.get('/test', () => {
  if (somethingBad) return new Response("that doesn't exist", { status: 404 });

  return 'yay';
});

Alternatively (or in addition to) throwing an error and attaching status should have the same affect. This can already be achieved manually today via custom onError handler to detect status in error. Ideally this would be out of the box behavior. Exposing ErrorStatus class would also make this type safe (ala throw new ErrorStatus('something wrong', 400)).

Awesome package otherwise!

[dodas]

+1

my two cents:

• sometimes it would be handy to be able to throw a response and have Elysia respond with it. For example, let's say in derive() we come across an error and want to respond instead of returning the derived context. Currently, throwing a response seems to respond with the correct status, but the response body is always empty.

• if we allow returning Response objects, we could also expose a generic Response interface, so we will be able to infer response type from Response.json(), similar to fets.

[kravetsone]

+1

my two cents:

• sometimes it would be handy to be able to throw a response and have Elysia respond with it. For example, let's say in derive() we come across an error and want to respond instead of returning the derived context. Currently, throwing a response seems to respond with the correct status, but the response body is always empty.
• if we allow returning Response objects, we could also expose a generic Response interface, so we will be able to infer response type from Response.json(), similar to fets.

fets has custom type implementation for the Response object

[kravetsone]

The docs aren't super clear on this subject, but I see no reason the formal Bun format could not auto translate.

Basically in addition to the current pattern, it would be very desirable to also support new Response:

// TODAY
app.get('/test', ({ set }) => {
  if (somethingBad) {
    set.status = 404;
    return "that doesn't exist";
  }

  return 'yay';
});

Would be great if this worked as well!

// NEXT
app.get('/test', () => {
  if (somethingBad) return new Response("that doesn't exist", { status: 404 });

  return 'yay';
});

Alternatively (or in addition to) throwing an error and attaching status should have the same affect. This can already be achieved manually today via custom onError handler to detect status in error. Ideally this would be out of the box behavior. Exposing ErrorStatus class would also make this type safe (ala throw new ErrorStatus('something wrong', 400)).

Awesome package otherwise!

this works today but for now it impossible to type Response object correctly (without custom type import)

[kravetsone]

+1

my two cents:

• sometimes it would be handy to be able to throw a response and have Elysia respond with it. For example, let's say in derive() we come across an error and want to respond instead of returning the derived context. Currently, throwing a response seems to respond with the correct status, but the response body is always empty.
• if we allow returning Response objects, we could also expose a generic Response interface, so we will be able to infer response type from Response.json(), similar to fets.

i guess it can be closed because main issue problem is solved