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,
  });
}

[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

[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 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!