microsite VS io-ts

None are ready for the public yet, but all in the hopper or under serious consideration:

- Personal site/blog with a bunch of algorithmically generated art and other fun stuff, built on Node/Preact but progressively enhanced/almost completely JS-free at runtime. Motivation for the build approach is that I’m on the low/no client JS static site bandwagon but I quite like the DX of JSX components and CSS-in-JS.

- I’m using a few excellent existing tools[1][2] for said site which unfortunately aren’t designed to work well together, so I have a variety of wrapper tooling that makes them live peacefully together. I’m also developing a bunch of other build-stage tools for my use cases. I plan to open source (or hopefully contribute back) all of that as soon as I’m satisfied with their quality.

- A set libraries for building declarative, type safe, automatically validated/documented service API boundaries (HTTP/REST to start, but I also plan to support other transport protocols) — think io-ts[3] type interfaces but you get swagger docs for free in a transport-agnostic interface. I’ve built this kind of thing before, it was wildly successful in real world use, but it’s proprietary to a previous employer and I’m starting over with all the stuff I learned in hindsight.

- A “nag me” app that’s basically “reading list” plus “reminders” with minimal config, eg “nag me soon” or “nag me after a while”. My personal use case is I frequently screenshot/text myself/etc stuff I want to look at later (usually on phone but need a computer to dive in), then it just goes down the memory hole. I’ve tried setting reminders but it’s often too much fuss, and I’m far too ADHD to use a passive list.

- Exploring building yet another FE build tool/bundler that’s explicitly multi-stage/sequential with static input/output validation, per-step/time travel debugging. Motivation is that existing tools are just a big ball of config magic and totally inscrutable. I’d likely wrap existing build tools because their set of responsibilities isn’t my motivation and I don’t want to introduce that much more new API surface area to weary FE devs.

[1]: https://github.com/natemoo-re/microsite

Microsite es un generador de sitios estáticos (SSG) construido sobre Snowpack y que utiliza Preact como framework.

Qué rico. Si tenés chance meté un proceso de code review fuerte, y para el tema de I/O probá a usar https://github.com/Effect-TS/schema ó https://github.com/gcanti/io-ts que les da una solución obvia al tema de "tipos para lo que devuelva el backend", aunque es en realidad mucho más capaz que eso.

My fave is still io-ts (https://github.com/gcanti/io-ts/blob/master/docs/index.md) as I find it more flexible than zod at the ingress. The author is also working on the Effect ecosystem which also looks interesting.

I’ve been using io-ts for this and been very happy with it. [1] It’s similar to Swift’s Coding protocol in case you’re familiar.

[1] https://gcanti.github.io/io-ts/

Yeah, there are a few new concepts and it's not the easiest to pick up right away. The best introduction is here on the main documentation page.

We use https://github.com/gcanti/io-ts/blob/master/Decoder.md which has a very similar interface. It can even be used to mutate the data using https://github.com/gcanti/io-ts/blob/master/Decoder.md#the-parse-combinator.

A good way to significantly improve the reliability of your app is via improving type-safety by moving away from using any to unknown. One relevant example could be when you type your backend responses and when stringifying JSON to using unknown combined with some sort of runtime type checking. It can be done either by using built-in functionality like type guards or using an external library like io-ts, zod or yup.

Usage of TypeBox is similar with io-ts and zod, but it is much powerful and faster than them. Also, TypeBox can generate JSON schema very easily. Therefore, if you're looking for a validator library for new project and not suffering from legacy codes, I think TypeBox would be much better choice than io-ts and zod. TypeBox can totally replace them.

This check can be done with different libraries like: io-ts, typebox, or zod. These libraries allow you to create objects that represent your typescript definitions. Then, these objects can be used at runtime to validate the received data, in addition, you can also convert this object to a Typescript definition to have all the benefits of using typescript. These objects can be called schema validations because they are responsible for the data validation.