Ioannis Georgiadis JohnGeorgiadis

Valibot Utils

Included

vTrimString -> validate it's a non-empty string after trimming for whitespace
vTrimStringOptional -> same as above, but allowing undefined. Converts empty strings (after trimming) to undefined
vAfter -> validate it's a base64 encoded JSON object + matches the given schema. Useful for encoded pagination variables, such as ?after={id: 10}
vCoerceObject -> coerce values from string to whatever the provided schema needs. Useful for parsing query strings, path params, etc.

Prerequisites

Async builder

DO NOT COPY THIS CODE INTO PRODUCTION!

For this specific example, you should use packages like zx or bun shell which are battle-tested shell script runners for javascript environments

This is meant to showcase what a builder pattern for await operators can do.

Example usage

API Construct for API Gateway V2

This gist represents an API construct on top of API Gateway V2. It's designed to make it easy to add lots of protected endpoints to a serverless API.

It introduces the following opinions:

Sandbox environments exist in the same AWS account as "dev"
There are only dev and production accounts - no test account
Dev and prod have static DNS records, but sandbox DNS records are dynamically generated by AWS
All API endpoints are authenticated by default. You opt out rather than in to authentication
All endpoints are either one verb only or all HTTP verbs. You cannot have a handler for only GET and POST but not PUT, for example. Instead, you must create separate endpoints for each verb (unless you use ANY, in which case your lambda will be triggered for all HTTP verbs on that endpoint)

10 Things You Are Doing Wrong in your Web Components

Web Components enable custom element creation and sharing on a whole new level that has not really been seen to date but is so desperately needed. Developers of everything from simple webpages to complex applications are using Web Components to deliver new functionality, new behaviors, and new designs. Web Components are a big part of the future of the web.

There are lots of articles detailing how to build a basic Web Component, but almost no article details how to solve some of the gotchas once you start down that road. That's what this article serves to do; point out some of the things every Web Component developer is overlooking and to which they should probably be giving more consideration.

1). Not Using a Web Component Framework

The APIs which make up the Web Components standards (Custom Elements, ShadowDOM, etc) are intentionally low level APIs. As such they are not always the most clear or concise in their understandability. Additionally,

	const md5File = require('md5-file');
	const path = require('path');

	// CSS styles will be imported on load and that complicates matters... ignore those bad boys!
	const ignoreStyles = require('ignore-styles');
	const register = ignoreStyles.default;

	// We also want to ignore all image requests
	// When running locally these will load from a standard import
	// When running on the server, we want to load via their hashed version in the build folder