Elysia 1.0 Breaking Changes / Migration about elysia

[SaltyAom]

@dodas update to elysia 1.0.6

[kabir-asani]

Returning an object in v1.0.3 is not converting to response to application/json type. Rather, it sends it out as a text/plain. How do I fix this?

[PureDizzi]

Returning an object in v1.0.3 is not converting to response to application/json type. Rather, it sends it out as a text/plain. How do I fix this?

@kabir-asani A quick workaround I found is to spread the object into another object.

e.g.
return { ...someObject }

[cybercoder-naj]

Hi! Is there any place I can contribute to updating the docs for v1?

[dodas]

How is this supposed to work with Plugins?
Consider this example:

import { Elysia } from "elysia";

const myPlugin = () => (a: Elysia) =>
  a.derive(() => ({ myPluginProp: 1 }));

const app = new Elysia()
  .use(myPlugin())
  .get("/my-plugin", ({ myPluginProp }) => {
//                      ^ Property 'myPluginProp' does not exist on type '{ body: unknown; ...
    return myPluginProp
  });

It seems the app actually gets myPluginProp on runtime (expected), just TS types say otherwise.

[dodas]

@SaltyAom any thoughts on this. Seems like this completely prevents usage of plugins using derive in v1.

[kabir-asani]

@PureDizzi Thank you!
This seems to be working but it's ugly.

We need a fix on this!

[april83c]

Returning an object in v1.0.3 is not converting to response to application/json type. Rather, it sends it out as a text/plain. How do I fix this?

@kabir-asani A quick workaround I found is to spread the object into another object.

e.g. return { ...someObject }

For correct typing in the Eden client, return { ...new Example() } as Example seems to work (this bug is so weird... has anyone made an issue for it yet?)

[SaltyAom]

Returning an object in v1.0.3 is not converting to response to application/json type. Rather, it sends it out as a text/plain. How do I fix this?

@kabir-asani A quick workaround I found is to spread the object into another object.

e.g. return { ...someObject }

For correct typing in the Eden client, return { ...new Example() } as Example seems to work (this bug is so weird... has anyone made an issue for it yet?)

I want to get this fix.
Can you provide some example that cause this problem?

[kabir-asani]

import { Elysia } from "elysia";

class Data {
    message: String;

    constructor(message: String) {
        this.message = message;
    }
}

const app = new Elysia()
    .get("/ping", ({ set }) => {
        const data = new Data("pong");

        set.status = 200;

        return data;
    })
    .listen(3000);

@SaltyAom
This snippet is enough to replicate the issue -- please check.

NOTE: What I've noticed is that the issue arises only when I try to access the set object.

[SaltyAom]

import { Elysia } from "elysia";

class Data {
    message: String;

    constructor(message: String) {
        this.message = message;
    }
}

const app = new Elysia()
    .get("/ping", ({ set }) => {
        const data = new Data("pong");

        set.status = 200;

        return data;
    })
    .listen(3000);

@SaltyAom This snippet is enough to replicate the issue -- please check.

NOTE: What I've noticed is that the issue arises only when I try to access the set object.

Hi, sorry for the slow response.

Unfortunately, this is an expected behavior and the case without using set is a bug.

Web Standard on different runtime has a slight implementation for mapping value to Response.

Some classes may expected to pass to Response directly while some classes are not on different implementation, instead of serializing all the unknown case, we leave this gray area for users to handle themself using either mapResponse or defining a serialization method using toString

In this case, if you are using a custom class, you may use toString method like this instead.

class Data {
	message: String

	constructor(message: String) {
		this.message = message
	}

	toString() {
		return JSON.stringify(this)
	}
}

[kabir-asani]

But is it really a fool-proof solution?
Because then I'd have to set Content-Type explicitly as well.

[dodas]

I propose this:

• have users define toJSON() method on their data classes, which returns the plain, json-serializable representation of the object
• have Elysia call toJSON() method if it's available and if so, respond with that along with Content-Type: application/json

[binyamin]

@SaltyAom I understand that you don't want to introduce breaking changes after v1. Have you seen #99 (comment)? I am biased, but that seems like an easy thing to slip in with other breaking changes.

[bogeychan]

@april83c, @kabir-asani, you can do something like this as a workaround:

const Data = class Object {
  message: String;

  constructor(message: String) {
    this.message = message;
  }
};

return new Data("yay") // inside handler

---

The problem is this switch on constructor name:

elysia/src/handler.ts

Line 159 in da63011

switch (response?.constructor?.name) {

[bogeychan]

or implement toJSON like this:

class Data {
  message: String;

  constructor(message: String) {
    this.message = message;
  }

  toJSON() {
    return structuredClone(this);
  }
}

That way you dont have to set Content-Type:

new Elysia()
  .get("/", () => {
    return new Data("yay").toJSON();
  })
  .listen(8080);

Its the same behaviour as return { "message": "yay" }