New API design

[aquapi]

Here's the new API design I'm thinking of that might looks more ergonomic. So instead of:

wrap({
  cyclePlugin: { hello }
})()
  .stdPetition({
    path: '/',
    method: 'GET',
    ...
  });

We can use:

vix()
  // Specify the plugin type as cycle in the plugin options
  .use(hello)
  .get('/', {
    ...
  });

[mimiMonads]

I know this is a way to make it more normal and I'm okay with it

.get('/', {
    f: () => 'hello world' 
  });

but the only issue is the return type, we have one mode where we return a Response and another one with a BodyInit, should we stick to returning a Response , do you like this new syntax @emastho

[emastho]

I know this is a way to make it more normal and I'm okay with it

.get('/', {
    f: () => 'hello world' 
  });

but the only issue is the return type, we have one mode where we return a Response and another one with a BodyInit, should we stick to returning a Response , do you like this new syntax @emastho

Well, this makes Vixeny more approachable to \<everyone>

The problem tho, it minimizes any uniqueness Vixeny had Under the hood its very unique, but to people its just "so this now just Elysia, but faster" Marketing is in shambles

[mimiMonads]

Maybe if we introduce get , post , put and delete and keep stdPetition ?

My idea of a serve implementation with the new syntax would be like:

await vix(opts)()
  .get({
    path: "/",
    f: () => new Response("hello world"),
  })
  .serve({
    port: 8080,
  });

Keeping all the current functionality, the problem I see with use is that we already set up everything in create

@emastho should I add .serve ?

[mimiMonads]

@aquapi also, I was thinking about adding addPetition instead of customPetition :

await vix(opts)()
  .addPetition({
    path: "/",
    f: () => new Response("hello world"),
  })
  .serve({
    port: 8080,
  });

and deprecate stdPetition , there's little use for it and it's confusing, keeping a Response as the object to return keeps consistency.