Eden Treaty feedback

[SaltyAom]

We would love to hear your thought, and feedback on your experience with Eden Treaty for an improvement.

You may come up with anything related to Eden Treaty, for example:

• proposing a new feature you want to see
• express dissatisfaction on area you wanted to have us improve (keep it constructive if possible)

If you don't know what to feedback, here's some example:

• How was your overall experience?
• Do you notice any lag on your IDE when using Eden Treaty?

Your feedback and idea will be used to improve Elysia and Eden Treaty for a better experience, thank you.

[scythewyvern]

First of all, I want to say that I really like and enjoy the experience of the developer of Elysia x Eden. I am very grateful for this wonderful library! ❤️

Features

I would like to be able to pass a function into the headers so that I can dynamically apply the data.
There may be other ways to do this, so please tell me.

import { edenTreaty } from '@elysiajs/eden'
import type { app } from 'server'

export const api = edenTreaty<typeof app>('http://localhost:3000', {
  $fetch: {
    headers: () => ({
      Authorization: `Bearer ${localStorage.getItem('__sessionId')}`,
    }),
  },
})

Now I have to pass sessionId to $headers every time.

const res = await api.auth.me.get({
  $headers: {
    Authorization: `Bearer ${localStorage.getItem('__sessionId')}`,
  },
})

Perfomance

I also noticed a large delay in autocompletion. I have about 15 routes in the application here.
Notice that I have "editor.quickSuggestionsDelay": 0, setting.

eden.mov

"@elysiajs/eden": "^0.8.0",
"elysia": "^0.8.8",
"typescript": "^5.2.2"

cpu: M1 Pro
vscode: 1.85.1 (Universal)

[amjed-ali-k]

I'm using clerk auth and getToken function is async. So i wish 😺

    headers: async () => ({
      Authorization: `Bearer ${await getToken()}`,
    }),

Instead of

export function useEden() {
  const { getToken } = useAuth();

  const fetcher = async (
    resource: string | URL | Request,
    init?: RequestInit
  ) => {
    return fetch(resource, {
      ...init,
      headers: {
        Authorization: `Bearer ${await getToken()}`,
        ...(init?.headers as any),
      },
    });
  };
  return edenTreaty<App>(isProd ? url : "/api/server/", {
    fetcher,
  });
}

[ptrxyz]

I'll also chime in to what @scythewyvern said:
Elysia is great, I like so many things about it! But for larger things...I feel the performance for type inference is just not there yet.
I usually follow the .use(...) pattern to encapsulate different services but it feels like that kills performance. I experience around 2 seconds for the auto-completion popup to appear as soon as your API is a few layers deep (app.some.thing.foo({ ... }).bar.get()). And at that point, there is barely any benefit besides type checking anymore. I am faster typing the routes out as a string than waiting for each part to show up :)

So yes, a boost here would be greatly appreciated.

[tkoehlerlg]

when will this come, I also need that for clerk! 🤤 @SaltyAom

[amjed-ali-k]

I've been utilizing Eden Treaty for about a month now, and it's significantly influenced my decision to use Elysia JS for my projects. The experience has been quite positive, but there are two enhancements that I believe could make Eden Treaty even more effective:

1. Infer Response and Request Types: My primary use of Eden Treaty is within event handlers, while for other scenarios, I rely on useSWR. Introducing an infer return type feature, similar to what's seen in hono, would be extremely beneficial. It would enable the creation of a more streamlined wrapper for useSWR, enhancing efficiency and ease of use.

2. Types from OpenAPI JSON: Another useful feature would be the ability for Eden to infer types directly from OpenAPI JSON, or a similar Eden-specific JSON format. This would alleviate the need to include everything in a monorepo, simplifying the development process and making the tool more flexible and adaptable to various project structures.

[fredericoo]

Yeah can relate, I had a hard time creating a hacky way to infer the response type from an endpoint and it’s very bad in performance.

[cmmartin]

I second the request to infer types. While Eden treaty is awesome, there's a lot more that goes into a client SDK like caching, revalidation, optimistic updates, etc which libraries like SWR are very good at. Unfortunately, it's difficult (impossible?) to integrate them because there's no easy to way to simply reference the return type of a route currently.

[fredericoo]

SWR infers the type from the fetcher function, although I agree with the ability to get return types, nowhere is SWR or react-query stopped from making use of those types 😆
const { data } = useSWR('a', ()=>edenTreaty.posts.get()) infers data just fine

[adarshaacharya]

is there any way we can infer the types now?

[adarshaacharya]

@fredericoo how did the hacky way, please do share

[fredericoo]

I absolutely love Elysia’s API and Eden is no less admired. Eden has made it much easier for me to sell the idea of us running our backend on it — we’re going to start a new project and Elysia has been picked as the technology!

With that said there’s always a bit of feedback, and here’s mine:

1. Autocompletion speed is not an issue, but a little annoyance. Is it ultra fast? no. Is it as fast as tRPC? no. Would I love it if it was? Absolutely. Does it stop me and my team from working? nope, it’s a matter of 2 seconds the first time and then the next uses seem to be cached by typescript pretty well. It definitely isn’t a make-or-break. I know how obsessed with perfection and performance, and despite me craving faster autocompletion, i’d much rather you and team focus in more pressing features.
2. The API is a little bit wonky with the index accessor operator, and with some subtle differences between "/" and "" as route paths. I’ve resourced to using Eden Fetch for how much more predictable it looks when fetching, with custom params or not. I wrote a proposal for a simple syntax change that would at least for me feel much more natural.

Overall, what a great time to be delving into http servers in typescript. Performance is through the roof and DX is unparalleled!

[itsyoboieltr]

Hey! My suggestions are already on the Eden Treaty repo as issues, so I will link them here if you would like to take a look at them:

1. [BUG] Param string unions eden#46
2. [BUG] Websocket data is not parsed, only returns string eden#37
3. Routing inconsistencies with and without prefix between '' and '/' eden#22
4. [FEATURE REQUEST] Transform function configuration eden#16, fix: transform entire object returned by execute eden#39
   • Even though my pr was merged, the type-safety part for the transform function was still not tackled, so the issue is not completely solved.

[MatthewAry]

Aside from type inference perf,

• I'd like to see better DX for intercepters/transformers for requests, such as when I need to add bearer tokens to each request. I had to override the fetch function for Eden Treaty. Or what if I wanted to globally intercept all errors? This can only be done through the transform hook. It would be nice if more granular hooks were exposed to the Treaty instance. Any of these low level hooks that modify the payload received by the caller that potentially modifies they response type should be reflected from the types returned by the caller.

• Also, I added (via PR) a getRaw function that lets us get direct access to the request object without Eden Treaty reading the stream. I don't like my solution very much, it's undocumented and lacks type safety. It would be good if there was a better implementation. The reason I even added this was because I couldn't download files using Eden Treaty. Eden Treaty would do well to support a broader set of response types out of the box.

• Recently have been seeing support for GraphQL with full type safety, via https://github.com/0no-co/gql.tada if it proves itself as a good solid for better GraphQL DX (note I have not studied it yet), it might be nice to see support for it added to Eden Treaty if it makes sense.

[iRyusa]

My only concern is the default behavior of Eden client side when you work with formData for uploading file through the API elysiajs/eden#32

[EllipticElysium]

Similar to what other before have requested, the main thing i'd like is being able to automate functionality for all requests, highest priority would be adding authorisation headers etc... so we don't have to add to each individual request

some kind of response handler that is run on all requests, even just trigger a function that is passed in the initialisation (with the respose passed as an unknown param)
Multiple uses for this, showing an error toast/popup or logging to sentry on failed requests, other actions for every request (perhaps updating a users permssions, or refreshing a session or smthn)

[fredericoo]

quick wrapper around it should do it no? I see eden as more low level solution, to be compared to fetch, not to axios or @tanstack/query. Implement auth, error handling however you want

[aquapi]

I recently take a look at Eden treaty proxy implementation.

• Property access is not cached
• Special path case like '/path' with '/path/get' will not work
• Personal preference: Just return a typed response like Hono HC

[m1212e]

I'll add my feedback for the new treaty here real quick:

I want to explicitly set the return type of my function. Previously I did this:

TreatyType["domain"][string]["user"][string]["get"];

now I need to do this:

 ReturnType<ReturnType<TreatyType["domain"]>["user"]>["get"]

which is a little more verbose but not too terrible. But one thing thats a problem which I didn't manage to solve yet is, that if I have multiple routes at that or parent locations, Typescript cannot say for sure that the return of the users call will have a get field since depending on my dynamic parameter object that I pass, there may be different route options. Thats a little annoying but I'll probably find a workaround.

Otherwise: Great work! Thanks!

[fredericoo]

it was never ideal, but now it’s less ergonomic. Ideally a utility type for error and one for data would be great!

[MatthewAry]

Would like to see an add-on extension to Eden to wrap https://tanstack.com/query with full type support.

[Sajeesh007]

In the documentation it says, if I have a path like this,

GET - /deep/nested
then I can access the endpoint as client.deep.nested.get()

but if I create a new Elysia instance (I followed MVC pattern) like this

I created the deep route as a group, then in the client, eden treaty is giving me the route as
client.deepnested.get() which is kind of not expected and giving 404.

but if I modify that to client.deep.nested.get() I can access my endpoint but I lose the type safety.

I guess this an issue.

[aquapi]

I think you should prefix the group name with /

[Sajeesh007]

I see, thanks that worked.

[adarshaacharya]

@Sajeesh007 whats the changes that you make, I'm loosing all the type safety.

[chneau]

Awesome client side!

I'm still unsure about how to use query params on the server and client, so I use body + POST everywhere for now.

I'm using tanstack query, and I have to modify the fetcher to throw error so that tanstack properly triggers onError:

const client = treaty<Server>(domain, {
	fetch: { credentials: "include" },
	fetcher: async (url, options) => {
		const response = await fetch(url, options);
		if (response.status >= 400) {
			const clone = response.clone();
			const data = await clone.json();
			throw data;
		}
		return response;
	},
});

Would be awesome to be able to configure treaty to throw errors with the message as an option.

Thanks for the library! I prefer Elysia + Treaty other anything else so far (express, hono)

[K4leri]

My pain using t.transform types in Eden treaty

const api = treaty(app);

const body = {
  id: "d8fb4d8c4at98FJ6898", // <--- this value is obfuscated
  update: {
    schedule: [
      {
        day: 1,
        time: [["10:00, 12:20"]],
        price: [2000],
      },
    ],
  },
};

it("returns a 200 status code when the update is successful", async () => {
  const response = await api.activity.create.put(
    //@ts-expect-error
    body,
    { headers: { authorization: accessToken } }
  );
  expect(response.status).toBe(200);
  expect(response.data).toEqual({
    data: {
      activity: expect.any(Array),
    },
  });
});

each test i should wright with //@ts-expect-error and if not to do this i will get error:

This is because i have

export const transformId = t
  .Transform(t.String())
  .Decode((value) => IdEncryptor.decryptId(value))
  .Encode((value) => IdEncryptor.encryptId(value));

const id = t.Object({
  id: transformId,
});

[jonyw4]

Is not working with Bun Workspaces