Open pyoner opened 3 days ago
I've organized my code like this:
// the v0.ts
import { App } from 'workery';
export function use<E>(app: App<E>) {
// my code here
// app.get('/', {})
}
// the main file
import { App } from 'workery';
import { use } from './v0';
const app = new App({});
use(app);
export default app;
You mean as in:
// a.ts
export const aRoutes = new Router<Env>({})
aRoutes.get("/", ...)
// index.ts
import { aRoutes } from "./a.ts"
const app = new App<Env>({})
app.extend("/a", aRoutes)
This feature is currently on my local files not yet committed, I can write some tests in a moment and push it later.
Some new features were added as well, finalizing tests and docs, I will push v1.1.0 tomorrow instead.
@iann838 wow great! thanks!
@pyoner
I have added an alpha version to npm for personal testing: workery@1.1.0-alpha.1
(with --tag alpha
). Documentation isn't finished yet, will probably need some weekend time for it. However, if you want to use it now here is what you asked for previously:
import { Include } from "workery"
const subapp = new Include<env>({})
subapp.get("/hello-world", {
parameters: {},
handle: () => "Hello World!",
})
app.include("/subpath", subapp)
There is only one breaking change between 1.0 and 1.1: Init of App
now instead of basePath
has rootPath
, this change was needed to differentiate the different behavior on the docs.
The API is finalized and is very unlikely to change from here until release candidate next week, so you should be safe to use it.
Although if you are not in a rush, I would suggest to wait for the new docs to come out first.
@iann838 I don't like how the new sub-routing API looks. I prefer Hono sub-routing.
const book = new Hono()
book.get('/', (c) => c.text('List Books')) // GET /book
book.get('/:id', (c) => {
// GET /book/:id
const id = c.req.param('id')
return c.text('Get Book: ' + id)
})
book.post('/', (c) => c.text('Create Book')) // POST /book
const app = new Hono()
app.route('/book', book)
What do you think about this sub-routing API?
// subapp.ts
import { App } from "workery"
const subapp = new App<env>({})
subapp.get("/hello-world", {
parameters: {},
handle: () => "Hello World!",
})
// main.ts
app.route('/sub-path', subapp)
@pyoner The issue here is that App
accepts many params that are only used for the main app. The Include
is a parent class of App
with only router capabilities. I personally felt conflicted by using App
for sub-routing, with most params being unused. Any ideas, this can still be modified as there is no release candidate. Possible naming alternatives are: UnboundApp
, SubApp
, Module
, AppRouter
@pyoner If I understand correctly, the main concern here is the naming of subapps, I can do SubApp
or refurbish the internal Router
// subapp.ts
const subapp = new SubApp<Env>({}) // or
const subapp = new Router<Env>({})
It cannot use App.route()
for adding sub app because it is already used for dynamic HTTP methods, so include
feels the closest.
Edit:
I am going ahead with Router
, which is the most verbose and describes the functionally clearly.
Published 1.1.0-alpha.2
import { Router } from "workery"
const subapp = new Router<Env>({})
subapp.get("/hello-world", {
parameters: {},
handle: () => "Hello World!",
})
app.include("/subpath", subapp)
Published
1.1.0-alpha.2
import { Router } from "workery" const subapp = new Router<Env>({}) subapp.get("/hello-world", { parameters: {}, handle: () => "Hello World!", })
app.include("/subpath", subapp)
This looks good! I'll try the alpha version.
@iann838 thank you for your work!
I didn't find any information in the documentation about how to create a complex router. I want to split my code into separate files.