One that gets me is when I want to add sanity checks into a TS library function. In reality, the library may be called from straight JS, so I want to check some things to handle edge cases in a reasonable way, but often TS's type checking itself gets in the way.
Very cool, starred. I did add an "issue" suggesting that you publish a docker image to make this easier to run without worrying about direct dependencies.
Nioe writeup on these non-mutating methods. It is worth noting that if you have *VERY* large arrays in React you may want to combine with a viewport handler so only the visible nodes are rendered in order to improve DOM performance. It's one of the few places that I will lean towards earlier than later optimization as it can get noticeable fairly quickly.
I generally do line delimited JSON output for stdout logging in production environmnets. This lends itself very well to log shipping and ingestion into services like ELK-stack and Cloudwatch etc.
For JS based services, I will enrich the context object with logging/timing support that will add in a few bits from the request object (path, method, etc). It tends to work pretty well.
The shape of my log entries are usually along the lines of...
{
level: Enum(LogLevel)
timestamp: DateTime,
message: String
req: {
path: String,
search: String,
started: DateTime,
elapsed: Number/Decimal (ms) - since started
},
res?: {
status: Number,
statusText: String,
comment?: String,
},
error?: Error
details?: Object
}
The signature's for logging are like...
ctx.log.debug
(message: string, details?: any) => ...
(error: Error, details?: any) => ...
res bits from ctx if set/available and not part of the error or details (status/statusText/comment). Message will come from the error, when passing an error.
It's tended to work pretty well.. I fclone the error/details object(s) for safety... errors will graft back a few pieces that are hidden from enumerated properties (trace, etc)... Depends on the LOG_LEVEL though.
I'd say it (Hono) is about half a step above Oak or Koa in that it's a similar pattern with a "standard" entry that works pretty well cross-environment... Native for Deno and Cloudflare (I think Bun too) and a small shim for Node.js, the only hard-ish part is there's some inconsistency between publishing of different parts between npm and jspm, also some of the environment specific modules were a bit more difficult to work out (at least in deno) as a result.
I've toyed with CF Workers/Pages deployments with Turso and D1... I want to like the CF hosting stuff, but have a few times had issues where I'm actively developing and the test environment deployments bork.
I haven't used Next/Nest enough to fairly comment on them. I'm not really a fan of page based routing, not to mention for apps, I don't really care about SEO, so have been fine with SPA React.
Cool to see stuff like this... that said, personally I've really gotten into basing most of my validation around zod... this works with hono/zod-openapi as well as client validation integration, so I'm able to get a lot of usage out of the same tools on both the client and server usage.
For server-side, with JS/TS I've gone heavy in with hono, recently used the zod + openapi integration, which has been very nice to use. I've also used C# with FastEndpoints library, which has also been very nice.
Client side, currently working with Mantine component library, though have used MUI a lot as well... for forms, I've used React + React-Hook-Form and zod indegration. Creating modest wrappers around form field elements in order to present error states and helper messages cleanly.
Not to detract from this Vue3 approach, just pointing out what I've used and that zod in particular has made things pretty nice all around, not just on the client.
See about page: - No commercial content or libraries (even with free demo)I generally do line delimited JSON output for stdout logging in production environmnets. This lends itself very well to log shipping and ingestion into services like ELK-stack and Cloudwatch etc. For JS based services, I will enrich the context object with logging/timing support that will add in a few bits from the request object (path, method, etc). It tends to work pretty well. The shape of my log entries are usually along the lines of... { level: Enum(LogLevel) timestamp: DateTime, message: String req: { path: String, search: String, started: DateTime, elapsed: Number/Decimal (ms) - since started }, res?: { status: Number, statusText: String, comment?: String, }, error?: Error details?: Object } The signature's for logging are like... ctx.log.debug (message: string, details?: any) => ... (error: Error, details?: any) => ... res bits from ctx if set/available and not part of the error or details (status/statusText/comment). Message will come from the error, when passing an error. It's tended to work pretty well.. I fclone the error/details object(s) for safety... errors will graft back a few pieces that are hidden from enumerated properties (trace, etc)... Depends on the LOG_LEVEL though.