brut 0.0.20 → 0.0.22

data/brutrb.com/.vitepress/theme/style.css

@@ -0,0 +1,149 @@
+/**
+ * Customize default theme styling by overriding CSS variables:
+ * https://github.com/vuejs/vitepress/blob/main/src/client/theme-default/styles/vars.css
+ */
+
+/**
+ * Colors
+ *
+ * Each colors have exact same color scale system with 3 levels of solid
+ * colors with different brightness, and 1 soft color.
+ *
+ * - `XXX-1`: The most solid color used mainly for colored text. It must
+ *   satisfy the contrast ratio against when used on top of `XXX-soft`.
+ *
+ * - `XXX-2`: The color used mainly for hover state of the button.
+ *
+ * - `XXX-3`: The color for solid background, such as bg color of the button.
+ *   It must satisfy the contrast ratio with pure white (#ffffff) text on
+ *   top of it.
+ *
+ * - `XXX-soft`: The color used for subtle background such as custom container
+ *   or badges. It must satisfy the contrast ratio when putting `XXX-1` colors
+ *   on top of it.
+ *
+ *   The soft color must be semi transparent alpha channel. This is crucial
+ *   because it allows adding multiple "soft" colors on top of each other
+ *   to create a accent, such as when having inline code block inside
+ *   custom containers.
+ *
+ * - `default`: The color used purely for subtle indication without any
+ *   special meanings attached to it such as bg color for menu hover state.
+ *
+ * - `brand`: Used for primary brand colors, such as link text, button with
+ *   brand theme, etc.
+ *
+ * - `tip`: Used to indicate useful information. The default theme uses the
+ *   brand color for this by default.
+ *
+ * - `warning`: Used to indicate warning to the users. Used in custom
+ *   container, badges, etc.
+ *
+ * - `danger`: Used to show error, or dangerous message to the users. Used
+ *   in custom container, badges, etc.
+ * -------------------------------------------------------------------------- */
+
+:root {
+  --vp-c-default-1: var(--vp-c-gray-1);
+  --vp-c-default-2: var(--vp-c-gray-2);
+  --vp-c-default-3: var(--vp-c-gray-3);
+  --vp-c-default-soft: var(--vp-c-gray-soft);
+
+  --blue-vp-c-brand-1: #0C00A7;
+  --blue-vp-c-brand-2: #6357FF;
+  --blue-vp-c-brand-3: #1000E2;
+  --blue-vp-c-brand-soft: #FAF9FF;
+
+  --vp-c-brand-1: #A70C00;
+  --vp-c-brand-2: #FF6357;
+  --vp-c-brand-3: #e21000;
+  --vp-c-brand-soft: #FFE7E5;
+
+  --xvp-c-brand-1: var(--vp-c-indigo-1);
+  --xvp-c-brand-2: var(--vp-c-indigo-2);
+  --xvp-c-brand-3: var(--vp-c-indigo-3);
+  --xvp-c-brand-soft: var(--vp-c-indigo-soft);
+
+  --vp-c-tip-1: var(--vp-c-brand-1);
+  --vp-c-tip-2: var(--vp-c-brand-2);
+  --vp-c-tip-3: var(--vp-c-brand-3);
+  --vp-c-tip-soft: var(--vp-c-brand-soft);
+
+  --vp-c-warning-1: var(--vp-c-yellow-1);
+  --vp-c-warning-2: var(--vp-c-yellow-2);
+  --vp-c-warning-3: var(--vp-c-yellow-3);
+  --vp-c-warning-soft: var(--vp-c-yellow-soft);
+
+  --vp-c-danger-1: var(--vp-c-red-1);
+  --vp-c-danger-2: var(--vp-c-red-2);
+  --vp-c-danger-3: var(--vp-c-red-3);
+  --vp-c-danger-soft: var(--vp-c-red-soft);
+}
+
+/**
+ * Component: Button
+ * -------------------------------------------------------------------------- */
+
+:root {
+  --vp-button-brand-border: transparent;
+  --vp-button-brand-text: var(--vp-c-white);
+  --vp-button-brand-bg: var(--vp-c-brand-3);
+  --vp-button-brand-hover-border: transparent;
+  --vp-button-brand-hover-text: var(--vp-c-white);
+  --vp-button-brand-hover-bg: var(--vp-c-brand-2);
+  --vp-button-brand-active-border: transparent;
+  --vp-button-brand-active-text: var(--vp-c-white);
+  --vp-button-brand-active-bg: var(--vp-c-brand-1);
+}
+
+/**
+ * Component: Home
+ * -------------------------------------------------------------------------- */
+
+:root {
+  --vp-home-hero-name-color: transparent;
+  --vp-home-hero-name-background: -webkit-linear-gradient(
+    120deg,
+    #333333 30%,
+    #d14141
+  );
+
+  --vp-home-hero-image-background-image: linear-gradient(
+    -45deg,
+    #ffe7e5,
+    #a70c00
+  );
+  --vp-home-hero-image-filter: blur(44px);
+}
+
+@media (min-width: 640px) {
+  :root {
+    --vp-home-hero-image-filter: blur(56px);
+  }
+}
+
+@media (min-width: 960px) {
+  :root {
+    --vp-home-hero-image-filter: blur(68px);
+  }
+}
+
+/**
+ * Component: Custom Block
+ * -------------------------------------------------------------------------- */
+
+:root {
+  --vp-custom-block-tip-border: transparent;
+  --vp-custom-block-tip-text: var(--vp-c-text-1);
+  --vp-custom-block-tip-bg: var(--vp-c-brand-soft);
+  --vp-custom-block-tip-code-bg: var(--vp-c-brand-soft);
+}
+
+/**
+ * Component: Algolia
+ * -------------------------------------------------------------------------- */
+
+.DocSearch {
+  --docsearch-primary-color: var(--vp-c-brand-1) !important;
+}
+

data/brutrb.com/ai.md

@@ -0,0 +1,68 @@
+# AI Declaration and Notes
+
+LLMs and AI tools are a current fact of life.  We feel it's important to be realistic and up front about
+how they affect this project.
+
+## Levels of AI Use
+
+I created [declare-ai.org](https://declare-ai.org/) to allow precise documentation of how AI is used in a
+project. It defines four levels of AI use:
+
+1. No involvement at all.
+2. Non-create assistance, such as the completions GitHub Copilot may make while you are typing.
+3. Creative assistance, where an AI generated a large amount of code that you then modified. An example would be using a tool like Cursor to write code for your review.
+4. Completely Produced by an AI, for example if you used Stable Diffusion to create your icon.
+
+## Code
+
+The entirety of Brut's codebase could be grouped into three parts:
+
+* The library code developers use. This is, roughly, the code in `lib`, `brut-js/src`, and `brut-css/src`.
+* Tests of the library code.
+* Tools used to manage the library code, such as what's in `bin/`, `brut-js/bin`, `brut-css/bin`, etc.
+
+### Library Code Should Be Written By a Person
+
+We want the library code written by a person, i.e. it should have level 1 AI assistance: none.  As of this writing—June 17, 2025—all library code was written by a person.
+
+If some code is level 2—non-creative assistance—that is probably fine.
+
+### Tests Should Not Be Totally Written by AI
+
+As of this writing—June 17, 2025—the library has no automated tests.  The `adrs.cloud` app serves as the
+test suite.
+
+That said, as tests are developed, they must never be written entirely by an AI without human review (level 4).  Our preference is that all tests comply with level 1 or level 2, however we are open to creative assistance for tests as might be provided by a tool like Cursor.
+
+In any case, the author of a test should understand it and the maintainers must be able to understand and
+modify all tests without the use of AI tools.
+
+### Management Tools Should Not Be Totally Written by AI
+
+Like tests, management tools must be comprehensible by a person and the creator of the code must
+understand it.  That said, some of the tools were created with level 3 AI assistance, and we expect these
+tools may continue to be created this way.
+
+Nevertheless, this code must be reviewed and understood by a person.
+
+## Documentation
+
+We strive to have all documentation written by a real person.  None of this documentation, or the API
+documentation, is produced by a machine, although spelling and grammar corrections will certainly have been suggested by automated tools.
+
+We expect an LLM to be able to digest this documentation and source code and provide alternate analysis of how Brut works and how to use it.  We hope such analysis is correct and useful, however that cannot be guaranteed, so this documentation is the second best source of truth, the source code being the best.
+
+## Logo
+
+The logo is level 4 - ChatGPT created it. I'd love to have a real person make a better one.  I just needed
+something to get this launched.  Please reach out if you want to make a better one + other assets. I'm
+willing to pay a real person.
+
+## AI That Teachs You About Brut Does Not Currently Exist
+
+Due to how LLMs work, there is naturally nothing in any model about Brut.  Anything an
+existing model tells you about Brut is **100% untrustworthy**.  We hope to allow LLMs to consume Brut's
+code, documentation, and examples, so it can be an additional source of help, but currently that is not
+the case.
+
+**Do not ask an LLM about Brut** until this part of the documentation changes.

data/brutrb.com/assets.md

@@ -0,0 +1,138 @@
+# Assets
+
+As mentioned in [Javascript](/javascript) and [CSS](/css), esbuild is used to bundle JavaScript and CSS. Brut also provides support for managing images.
+
+## JavaScript and CSS
+
+Both JavaScript and CSS are managed largely the same way: esbuild is given `app/src/front_end/js/index.js` or
+`app/src/front_end/css/index.css` and a bundle is produced.
+
+For both JS and CSS, the bundles are *hashed*, even in development.  This is to reduce differences in production
+and development.  The `asset_path` helper can translate the logical path (`/js/app.js` or `/css/styles.css`) into
+the specific hashed path.
+
+Sourcemaps are provided as well, for both development and production.
+
+### What is Hashing and Why Do It?
+
+In production, while your pages produce dynamic data, the CSS and JavaScript bundles themselves are not dynamic.
+They are the same for every single request until you change them. Because of this, it's common to configure a
+cache for these files. Often, that cache is a *content delivery network* or CDN.
+
+When a page is rendered, the browser will ask for the CSS and JS bundles. The CDN will tell the browser it's
+OK to cache the file, potentially for a very long time (years).  On subsequent requests for those files, the
+browser will re-use its cached copy, saving bandwidth and time.
+
+A downside of this approach is when you *do* want to change something.  While most CDNs allow you to invalidate
+their cached values, there are many layers of caching whose behavior can be hard to control.  It turns out to be
+much simpler to rename the file each you change it, thus "breaking the cache".
+
+A common way to do this is to create a hash of the file's contents and append that value to its name, so instead
+of `/static/css/styles.css`, the file would `/static/css/styles-98724fhjkjk.css`.  When you make a change to
+your CSS, it'll get new name, say `/static/css/styles-3yjgdrjksrfdws.css`.
+
+To keep you from having to deal with this directly, Brut's `asset_path` helper will translate a logical name like
+`/css/styles.css` to the actual name, like `/static/css/styles-3yjgdrjksrfdws.css`.
+
+### What are SourceMaps and Why Create Them?
+
+Bundled JavaScript and CSS will have been *minified*.  This means removing whitespace, line breaks and, in the
+case of JavaScript, potentially changing the actual names of classes and variables.  This is all to reduce the
+size of the file as much as possible without changing its meaning.
+
+In your browser's dev tools, all your CSS is one the first line of `styles.css` and every stack trace from your
+JavaScript is on line 1 of `app.js`.  This is not helpful for diagnosing issues.
+
+*SourceMaps* are separate files that translate the minified files back to normal ones, so you can see a normal
+stack trace with the actual line numbers of your source files.
+
+There are many ways to create source maps and if you've used a tool like WebPack, you'll recall that many of them
+don't produce usable source maps.  Brut uses esbuild's facility for this, with a focus on correctness. When
+you see a line number and a source file in your browser, you can be sure it's accurate.
+
+The tradeoff is that it can take longer to produce than producing an inaccurate one. I'm not sure who wants
+inaccurate source maps, but Brut does not support this. In practice, esbuild is quite fast, so it should not make
+a practical difference in your day to day work.
+
+
+## Fonts
+
+Custom fonts are managed implicitly by esbuild's managing of CSS.  In your CSS, you should reference fonts as
+relative to the CSS file.  For example, if you have the font `app/src/front_end/fonts/monaspace-xenon.ttf`, then
+your `app/src/front_end/css/index.css` should look like so:
+
+```css {3}
+@font-face {
+  font-family: "Monaspace Xenon";
+  src: url("../fonts/monaspace-xenon.ttf") format("truetype");
+  font-display: swap;
+}
+```
+When CSS is bundled, esbuild will copy and hash the fonts, then rewrite the CSS to reference them.
+
+Brut does not support font management in any other way.
+
+## Images
+
+Brut supports managing images, and will `rsync` them from `app/src/front_end/images` to
+`app/public/static/images`, where you can reference them via `/static/images/«image_name»`.
+
+Brut does not support hashing of image names.
+
+You can reference images like so:
+
+```ruby
+def view_template
+  div do
+    # Renders app/src/front_end/images/foo.png
+    img src: "/static/images/foo.png", alt: "Picture of a foo"
+  end
+end
+```
+
+## SVGs
+
+You can place `.svg` files in `app/src/front_end/images` if you wish to use them in `<img>` tags.  However, if
+you place svgs in `app/src/front_end/svgs`, they can be inlined into your HTML via `inline_svg`.  In this case,
+there is no need for a build step, since the SVG source is included directly in your HTML. This works well
+for icons.
+
+## `favicon.ico`
+
+`Brut::FrontEnd::Middlewares::Favicon` is configured by default to handle requests for `/favicon.ico`.  It
+returns a 301 to `/static/images/favicon.ico`. This means that Brut expects
+`app/src/front_end/images/favicon.ico` to exist.
+
+
+## All Other Assets
+
+Brut currently does not support any other managed asset. However, you can place files in `app/public/static` and
+they will be served up directly.
+
+
+## Technical Notes
+
+> [!IMPORTANT]
+> Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut's
+> internals, the source code is always more correct.
+
+_Last Updated May 7, 2025_
+
+`bin/build-assets` manages all of the behavior described on this page.  `bin/build-assets css` and
+`bin/build-assets js` modify the file `app/config/asset_metadata.json`, which stores the mappings between logic
+paths and hashed paths:
+
+```json
+{
+  "asset_metadata": {
+    ".js": {
+      "/js/app.js": "/js/app-7MMIZXTZ.js"
+    },
+    ".css": {
+      "/css/styles.css":"/css/styles-ZAISBLGE.css"
+    }
+  }
+}
+```
+
+As you can see, this format could support multiple bundles and additional file types.

data/brutrb.com/bin/build

@@ -0,0 +1,5 @@
+#!/bin/bash
+
+set -e
+
+npm run docs:build

data/brutrb.com/bin/deploy

@@ -0,0 +1,7 @@
+#!/bin/bash
+
+set -e
+
+bin/build
+rsync -av --delete .vitepress/dist/ ../docs/
+echo "brutrb.com" > ../docs/CNAME

data/brutrb.com/bin/dev

@@ -0,0 +1,5 @@
+#!/bin/bash
+
+set -e
+
+npm run docs:dev

data/brutrb.com/bin/setup

@@ -0,0 +1,5 @@
+#!/bin/bash
+
+set -e
+
+npm install

data/brutrb.com/brut-js.md

@@ -0,0 +1,117 @@
+# BrutJS
+
+Brut includes the JavaScript library *BrutJS* which provides HTML custom elements that are useful for
+progressively enhancing your HTML.
+
+## Overview
+
+By default, your app is set up to use BrutJS.  This is done by defining all the custom elements it
+provides. Their source code is included in your JavaScript bundle, but they do not do anything until you
+use one of the custom elements.
+
+Here's what `app/src/front_end/js/index.js` looks like initially:
+
+```javascript
+import { BrutCustomElements } from "brut-js"
+
+document.addEventListener("DOMContentLoaded", () => {
+  BrutCustomElements.define()
+})
+``` 
+
+Further, `Brut::FrontEnd::Component` uses Phlex's `register_element` to register all the elements so you
+can use them at will in components or pages:
+
+```ruby
+def view_template
+  form do
+    input type: "text", name: "name"
+    brut_confirm_submit message: "Are you sure?" do
+      button { "Submit" }
+    end
+  end
+end
+```
+
+### Custom Elements
+
+The JSDoc for these elements' classes should provide complete documentation, however this is an overview
+of what each one does.
+
+| Element                      | Purpose |
+|---|---|
+| `<brut-ajax-submit>`         | Allows submitting a form via Ajax. Handles the use of `fetch` and all possible cases, but you still provide the logic for what to do with the response. |
+| `<brut-autosubmit>`          | Auto submits a form when a `<select>`'s option is chosen.        |
+| `<brut-confirmation-dialog>` | Enhances a `<dialog>` to make it easier to use as a generic confirmation with `<brut-confirm-submit>` |
+| `<brut-confirm-submit>`      | Uses `window.confirm` or your owned styled `<dialog>` to confirm a button click. |
+| `<brut-cv>`                  | Like `<brut-message>` but specific to constraint violations, namely having additional logic for subsituting the field name in the message. |
+| `<brut-cv-messages>`         | Wraps `<brut-cv>` elements related to a single form input.        |
+| `<brut-copy-to-clipboard>`   | Allows the button inside it to copy text from another element onto the clipboard.        |
+| `<brut-form>`                | Manages client-side constraint violation UX unified with the server-side, as well as a few quality-of-life improvements for client-side violations and styling. See [Forms](/forms#forms-and-constraint-violations).|
+| `<brut-i18n-translation>`    | Holds the translated value for a single key in the web site visitor's locale.        |
+| `<brut-locale-detection>`    | Sends an Ajax request to the server with the browser's reported locale and timezone.  See [space-time continuum](/space-time-continuum#getting-timezone-from-the-browser) for more details.        |
+| `<brut-message>`             | Shows a message using an [i18n](/i18n) key to dynamically pull a localized message for client-side constraint violations. |
+| `<brut-tabs>`                | Uses ARIA roles related to a tab control and implements it client-side. |
+| `<brut-tracing>`             | Sends observability data back to the server to unify a server-side request with client-side tracing.|
+
+> [!NOTE]
+> BrutJS's elements were created only to solve specific issues in the apps Brut was initially used for.
+> It's hoped that more elements will be added to provide a more feature-complete set of primitives to
+> create client-side enhancements.
+
+### Creating Your Own Custom Elements
+
+BrutJS includes a base class, [`BaseCustomElement`](/brut-js/api/BaseCustomElement.html), you can use to
+create your own custom elements with a bit more help, but not too much.
+
+The documentation for `BaseCustomElement` has an example, but here are the features you get (noting that
+you aren't abandoning the web platform's API, merely gaining a few additional quality-of-life
+improvements):
+
+* The ability to add debugging statements that are disabled via markup, not commenting-out `console.log`
+* Per-attribute change callbacks so you don't have to create `attributeChangedCallback` as a giant `if/else` block.
+* Default implementations of `connectedCallback` and `attributeChangedCallback` that call the template method `update`, thus allowing your element to centralize its logic in one place, regardless of how a state change was triggered.
+* Static `define()` method that defines your element based on its static `tagName` field. This allows richer interaction of elements, as you can do e.g. `document.querySelector(SomeOtherElement.tagName)`  and better navigate changes to your code over time.
+
+If you are familiary with the API for autonomous custom elements, `BaseCustomElement` doesn't require
+learning much more.  What you know already will be leveraged.
+
+### Removing BrutJS
+
+To remove BrutJS from your app, modify `app/src/front_end/js/index.js` to remove the `import` and call to
+`define()`.  You can then remove it from your `package.json`.
+
+**Note** If you remove it like this, several features will not work, including locale detection, client-side observability, and client-side form validation UX.
+
+## Recommnded Practices
+
+Consider this decision tree from Alex Russell's [If Not React, Then
+What?](https://infrequently.org/2024/11/if-not-react-then-what/):
+
+![Tree showing an SPA decision](/images/spa.png)
+
+This is how Brut wants you to consider your app's architecture.  *Many* apps do not have long-running
+sessions where visitors make lots of updates to data.  Most so-called "CRUD" apps do not fall into this
+category. The visitor would be better served by a traditional app with server-side HTML generation and
+minimal interactivity.  Visitors would also be better served with progressively enhanced features instead
+of massive JS payloads that show white screens on low bandwidth/low performance devices.
+
+Thus, Brut recommends you design your app to work in a tranditional multi-page app sort of way, then
+*enhance* as needed using autonomous custom elements.
+
+You can, of course, bring in whatever framework you like and use that in the normal way.  BrutJS's custom
+elements should work with any framework.
+
+## Testing
+
+See [Testing Custom Elements](/custom-element-tests).
+
+## Technical Notes
+
+> [!IMPORTANT]
+> Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut's
+> internals, the source code is always more correct.
+
+_Last Updated June 15, 2025_
+
+None.

data/brutrb.com/business-logic.md

@@ -0,0 +1,55 @@
+# Business or Domain Logic
+
+Since business and domain logic is not required, nor encouraged, to go in your data models, where does it go?
+
+It can go anywhere you like - Brut is not currently prescriptive.
+
+## Overview
+
+It's recommended that you place classes in `app/src/back_end`.  Any directory created in there will be
+auto-loaded by Brut/Zeitwerk based on its rules.  This means that classes in any directory in `app/src/back_end`
+should not be namespaced.
+
+For example, if you have *commands* and *queries*, you may want them in `app/src/back_end/commands` and
+`app/src/back_end/queries`, respectively.  In this case, `NewOrganizationCommand` would go in
+`app/src/back_end/commands/new_organization_command.rb` and `AccountQuery` would go in
+`app/src/back_end/queries/account_query.rb`
+
+Or, you could could organize them into `app/src/back_end/business_logic/commands` and `app/src/back_end/business_logic/queries`.  In that case, `Commands::NewOrganization` would be expected in `app/src/back_end/business_logic/commands/new_organization.rb` and `Queries::Account` would be expected in `app/src/back_end/business_logic/queries/account.rb`.
+
+How you organize it is up to you.
+
+## Testing
+
+Tests can be written using RSpec in the usual way.  Spec files should be in
+`specs/back_end/path/to/class.spec.rb`.  Note that Brut expects Spec files to end in `.spec.rb` and *not*
+`_spec.rb`.
+
+There is nothing special about the tests for your domain logic. Write them however you need to.
+
+## Recomended Practices
+
+This could be an entire series of books.  The main recommendation is to take a light approach and don't
+immediately install complex frameworks or libraries unless you know you need them.
+
+Something somewhere in your business logic will need to interface with your front-end.  The simplest way to do
+that is to allow form objects to be passed into your back-end.  The second simplest way is to pass form values
+into your back-end.
+
+You are strongly discouraged from having your front-end locate data models and pass those to your back-end.  This
+can be done while prototyping and for fast iteration on a concept, but generally you do not want to query your
+database from your handlers or pages just to pass the results into a back-end class.
+
+Exposing data models to the front-end is generally OK, as that is sometimes what you need to do.
+
+## Technical Notes
+
+> [!IMPORTANT]
+> Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut's
+> internals, the source code is always more correct.
+
+_Last Updated May 7, 2025_
+
+Creating universal abstractions from business logic is difficult. Brut is unlikely to do this. If it does, it
+will be after much analysis of exsiting patterns and *only* if it helps avoid mistakes and increases developer
+throughput.