Casey Watts caseywatts

Decap Widgets for USWDS Components

Decap offers custom widgets, that can be added from Decap's markdown editor.

Dependencies:

Some widgets here use the UWSDS core library (e.g. usa-button class must be available)
Some depend on OGDS Elements (an implementation of USWDS). This is needed to make the markup simple enough for it to be reliable parsing with a regular expression (RegEx).

Widgets:

USWDS Button link (for a call to action)
the usa-button class must be available, from USWDS

Using Eleventy for USWDS projects

This eleventy config does several things to make it easier to work with USWDS:

Exposes a filter asMarkdown that can be used in hard-coded (non-markdown) HTML files. This uses the same markdown parser that Markdown uses, to prevent issues with having multiple instances or libraries.
External links get formatted as usa-link--external, and open in a new tab
Lists are formatted with usa-list
The typographer setting is enabled, giving us features like smart quotes.

These below snippets go into admin/main.js

When looking at a running CI job, it's nice to see some progress occur so you know it's not stuck. Without this formatter, if you look at a running RSpec job, it looks stuck, because it doesn't display any output until it's run every test.

This formatter was created by a coworker, but I wanted to share this out in case it helps other folks!

How can we automate generation of AASM diagrams, so our documentation will always be up to date with our code?

This gist does two main things that the aasm-diagram repo doesn't do on its own as of today (May 2025):

Finds all of the uses of aasm in our Rails models itself, so we don't have to list them out
Updates a markdown file that embeds each of the AASM diagrams

When should we generate this?

rails-erd uses database migrations as the moment to auto-generate an ERD diagram, which makes a ton of sense!

This is a proof of concept, re-creating USWDS styles in MJML.

Why?

Email clients don't render everything the same way as web browsers -- for example, <button> element is not supported in email clients. There are many workarounds to get buttons to work in many email clients, each with pros and cons.

How?

Tools like MJML help make this easier, by providing an abstraction layer over the complex markup we need to ensure cross-email-client compatibility.

	const params = new Proxy(new URL(window.location), {
	get: (url, prop) => url.searchParams.get(prop),
	set: (url, prop, value) => {
	url.searchParams.set(prop, value);
	window.history.replaceState({}, "", url);
	},
	});
	window.addEventListener("DOMContentLoaded", async (event) => {
	// initialize the search UI
	const search = await new PagefindUI({

	// reading from the search parameter
	console.log(params.q);

	// writing to the URL in the navigation bar
	params.q = "new query";

	import { html, LitElement } from "lit";
	import { customElement, property } from "lit/decorators.js";
	import { submit } from "@open-wc/form-helpers";
	import { importMdwdsLinkTag } from "../../lib/mdwdsAssetsPath.js";

	@customElement("login-gov-button")
	export class LoginGovButton extends LitElement {
	@property({ type: Boolean })
	big = false;

	import { css, html, LitElement, nothing } from "lit";
	import {
	customElement,
	property,
	queryAssignedNodes,
	state,
	} from "lit/decorators.js";

	const sharedCSS = css`
	:host {