brut 0.14.0 → 0.15.0

data/docs/assets/{custom-element-tests.md.B_rbta32.js → custom-element-tests.md.DiLe-eFw.js}

@@ -1,4 +1,4 @@
-import{_ as i,c as a,o as t,ag as n}from"./chunks/framework.1L-BeKqY.js";const o=JSON.parse('{"title":"Testing Custom Elements","description":"","frontmatter":{},"headers":[],"relativePath":"custom-element-tests.md","filePath":"custom-element-tests.md"}'),e={name:"custom-element-tests.md"};function h(l,s,p,k,E,r){return t(),a("div",null,s[0]||(s[0]=[n(`<h1 id="testing-custom-elements" tabindex="-1">Testing Custom Elements <a class="header-anchor" href="#testing-custom-elements" aria-label="Permalink to &quot;Testing Custom Elements&quot;">​</a></h1><p>While simple custom elements can be tested as part of an <a href="/end-to-end-tests.html">end-to-end test</a>, more complex custom elements can benefit from a unit test. Spoiler: this is not going to be pleasant.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>BrutJS provides a testing module that uses JSDom to allow you to test your custom elements. There are downsides to JSDom, but it&#39;s the simplest way to achieve a reasonably-useful unit test.</p><p>You can use <code>bin/scaffold</code> to create a test, which will create a <code>.spec.js</code> file in <code>specs/front_end/js/</code>. Suppose we the custom element <code>MyElement</code>:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>&gt; bin/scaffold custom_element_test app/src/front_end/js/MyElement.js</span></span></code></pre></div><p>This creates <code>specs/front_end/js/MyElement.spec.js</code>:</p><div class="language-javascript vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">javascript</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">import</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> { withHTML } </span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">from</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;brut-js/testing/index.js&quot;</span></span>
+import{_ as i,c as a,o as t,ag as n}from"./chunks/framework.C4nOkCZI.js";const o=JSON.parse('{"title":"Testing Custom Elements","description":"","frontmatter":{},"headers":[],"relativePath":"custom-element-tests.md","filePath":"custom-element-tests.md"}'),e={name:"custom-element-tests.md"};function h(l,s,p,k,E,r){return t(),a("div",null,[...s[0]||(s[0]=[n(`<h1 id="testing-custom-elements" tabindex="-1">Testing Custom Elements <a class="header-anchor" href="#testing-custom-elements" aria-label="Permalink to &quot;Testing Custom Elements&quot;">​</a></h1><p>While simple custom elements can be tested as part of an <a href="/end-to-end-tests.html">end-to-end test</a>, more complex custom elements can benefit from a unit test. Spoiler: this is not going to be pleasant.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>BrutJS provides a testing module that uses JSDom to allow you to test your custom elements. There are downsides to JSDom, but it&#39;s the simplest way to achieve a reasonably-useful unit test.</p><p>You can use <code>bin/scaffold</code> to create a test, which will create a <code>.spec.js</code> file in <code>specs/front_end/js/</code>. Suppose we the custom element <code>MyElement</code>:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>&gt; bin/scaffold custom_element_test app/src/front_end/js/MyElement.js</span></span></code></pre></div><p>This creates <code>specs/front_end/js/MyElement.spec.js</code>:</p><div class="language-javascript vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">javascript</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">import</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> { withHTML } </span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">from</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;brut-js/testing/index.js&quot;</span></span>
 <span class="line"></span>
 <span class="line"><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">describe</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;&lt;some-element&gt;&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">, () </span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">=&gt;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> {</span></span>
 <span class="line"><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">  withHTML</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">\`</span></span>
@@ -66,4 +66,4 @@ import{_ as i,c as a,o as t,ag as n}from"./chunks/framework.1L-BeKqY.js";const o
 <span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">input.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">dispatchEvent</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">new</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> InputEvent</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;input&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">, {}))        </span></span>
 <span class="line"></span>
 <span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;">// works</span></span>
-<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">input.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">dispatchEvent</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">new</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> window.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">InputEvent</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;input&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">, {}))</span></span></code></pre></div><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><p>The custom element test library is <em>very</em> basic. Testing asychronous things like <code>fetch</code> is extremely difficult. Your best bet is to use these tests for edge cases and error conditions.</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated June 13, 2025</em></p><p>I will be honest with you, this part of Brut needs a lot of work and thinking-through. It&#39;s way to DSL-tasitc for my tastes, but it does work for some needs. JSDom is not ideal and requires a lot of hoops when using events or anything browsers support that it does not.</p><p>This is highly likely to change. My current thinking on addressing the need is to run the tests in a real browser and to make the test setup and code more like what you&#39;d actually write when using these elements.</p>`,26)]))}const g=i(e,[["render",h]]);export{o as __pageData,g as default};
+<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">input.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">dispatchEvent</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">new</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> window.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">InputEvent</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;input&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">, {}))</span></span></code></pre></div><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><p>The custom element test library is <em>very</em> basic. Testing asychronous things like <code>fetch</code> is extremely difficult. Your best bet is to use these tests for edge cases and error conditions.</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated June 13, 2025</em></p><p>I will be honest with you, this part of Brut needs a lot of work and thinking-through. It&#39;s way to DSL-tasitc for my tastes, but it does work for some needs. JSDom is not ideal and requires a lot of hoops when using events or anything browsers support that it does not.</p><p>This is highly likely to change. My current thinking on addressing the need is to run the tests in a real browser and to make the test setup and code more like what you&#39;d actually write when using these elements.</p>`,26)])])}const g=i(e,[["render",h]]);export{o as __pageData,g as default};

data/docs/assets/custom-element-tests.md.DiLe-eFw.lean.js

@@ -0,0 +1 @@
+import{_ as i,c as a,o as t,ag as n}from"./chunks/framework.C4nOkCZI.js";const o=JSON.parse('{"title":"Testing Custom Elements","description":"","frontmatter":{},"headers":[],"relativePath":"custom-element-tests.md","filePath":"custom-element-tests.md"}'),e={name:"custom-element-tests.md"};function h(l,s,p,k,E,r){return t(),a("div",null,[...s[0]||(s[0]=[n("",26)])])}const g=i(e,[["render",h]]);export{o as __pageData,g as default};

data/docs/assets/{database-access.md.gnluu54N.js → database-access.md.Dc8l2Plf.js}

@@ -1,4 +1,4 @@
-import{_ as a,c as i,o as e,ag as t}from"./chunks/framework.1L-BeKqY.js";const c=JSON.parse('{"title":"Database Access / Data Models","description":"","frontmatter":{},"headers":[],"relativePath":"database-access.md","filePath":"database-access.md"}'),n={name:"database-access.md"};function l(h,s,p,o,d,k){return e(),i("div",null,s[0]||(s[0]=[t(`<h1 id="database-access-data-models" tabindex="-1">Database Access / Data Models <a class="header-anchor" href="#database-access-data-models" aria-label="Permalink to &quot;Database Access / Data Models&quot;">​</a></h1><p>Brut provides access to the database via the <a href="https://sequel.jeremyevans.net/" target="_blank" rel="noreferrer">Sequel library</a>. Sequel is fully featured and provides a lot of ways of interacting with and managing your database. Brut includes several plugins and extensions to provide opinionated default behavior or additional features.</p><p>One thing to keep in mind is that Brut refers to your database layer as <em>database models</em> (notably not the un-qualified &quot;models&quot;). Brut treats this layer as a <em>model</em> of your database, not a model of your <em>domain</em> (though you are free to conflate the two).</p><p>This section details how to access data in your database.</p><div class="note custom-block github-alert"><p class="custom-block-title">NOTE</p><p>Brut currently only supports Postgres. Sequel supports many database systems, however Brut&#39;s extensions are currently geared toward Postgres only.</p></div><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Accessing your database in Brut uses Sequel&#39;s <code>Sequel::Model</code>. A base class called <code>AppDataModel</code> exists in your app from which all other data models extend:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"># app/src/back_end/data_models/app_data_model.rb</span></span>
+import{_ as a,c as i,o as e,ag as t}from"./chunks/framework.C4nOkCZI.js";const c=JSON.parse('{"title":"Database Access / Data Models","description":"","frontmatter":{},"headers":[],"relativePath":"database-access.md","filePath":"database-access.md"}'),n={name:"database-access.md"};function l(h,s,p,o,d,k){return e(),i("div",null,[...s[0]||(s[0]=[t(`<h1 id="database-access-data-models" tabindex="-1">Database Access / Data Models <a class="header-anchor" href="#database-access-data-models" aria-label="Permalink to &quot;Database Access / Data Models&quot;">​</a></h1><p>Brut provides access to the database via the <a href="https://sequel.jeremyevans.net/" target="_blank" rel="noreferrer">Sequel library</a>. Sequel is fully featured and provides a lot of ways of interacting with and managing your database. Brut includes several plugins and extensions to provide opinionated default behavior or additional features.</p><p>One thing to keep in mind is that Brut refers to your database layer as <em>database models</em> (notably not the un-qualified &quot;models&quot;). Brut treats this layer as a <em>model</em> of your database, not a model of your <em>domain</em> (though you are free to conflate the two).</p><p>This section details how to access data in your database.</p><div class="note custom-block github-alert"><p class="custom-block-title">NOTE</p><p>Brut currently only supports Postgres. Sequel supports many database systems, however Brut&#39;s extensions are currently geared toward Postgres only.</p></div><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Accessing your database in Brut uses Sequel&#39;s <code>Sequel::Model</code>. A base class called <code>AppDataModel</code> exists in your app from which all other data models extend:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"># app/src/back_end/data_models/app_data_model.rb</span></span>
 <span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">AppDataModel</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> =</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> Class</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">.</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">new</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">Sequel</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">Model</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">)</span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">class</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> AppDataModel</span></span>
 <span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;">  # You can insert your own shared methods here</span></span>
@@ -60,4 +60,4 @@ import{_ as a,c as i,o as e,ag as t}from"./chunks/framework.1L-BeKqY.js";const c
 <span class="line highlighted"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">      }.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">to</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> raise_error</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#DBEDFF;">/email_must_be_domain/</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">)           </span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">    end</span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">  end</span></span>
-<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">end</span></span></code></pre></div><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><h3 id="do-not-put-business-logic-on-your-database-models" tabindex="-1">Do Not Put Business Logic On Your Database Models <a class="header-anchor" href="#do-not-put-business-logic-on-your-database-models" aria-label="Permalink to &quot;Do Not Put Business Logic On Your Database Models&quot;">​</a></h3><p>There&#39;s no reason to, or benefit to doing so. What you&#39;ll find is that any app of even moderate complexity will not have a strict mapping from page to business concept to database table. Rather, these things will all differ greatly, and each serves a different purpose.</p><p>The job of your data models—and the tables they provide access to—is to store reliable and unambiguous data. Their job is to ensure there is no bad data such that when you ask the database a question, you get a reliable and correct answer.</p><p>Your views and business logic do not have this exact same job.</p><p>As such, your models should only contain:</p><ul><li>configuration to allow navigating the database.</li><li>methods to manage type conversions between your types and the strings or numbers required in the database</li><li>methods to query the data based on data definitions (not business logic).</li></ul><p>Business logic and data models <em>do</em> overlap at times, so there is some judgement in maintaining a clear separation of concerns. One way to manage this is to always put all logic elsewhere until you see a pattern of re-use that leads you to extract that logic to a data model.</p><h3 id="do-not-use-validations-on-models-unless-there-is-no-other-choice" tabindex="-1">Do Not Use Validations on Models Unless There is No Other Choice <a class="header-anchor" href="#do-not-use-validations-on-models-unless-there-is-no-other-choice" aria-label="Permalink to &quot;Do Not Use Validations on Models Unless There is No Other Choice&quot;">​</a></h3><p>Sequel provides a validation layer for use on models. You should not generally use this, since a) data integrity is baked into your database design, and b) user interactions and constraints are part of the front-end.</p><p>That said, there are times when you have data constraints that cannot be modeled in the database. In that case, a validation on the data model is better than nothing. Since all data access for your app should go through your data models, a validation on a data model has a high chance of being checked.</p><div class="note custom-block github-alert"><p class="custom-block-title">NOTE</p><p>Since any process, app, or tool can manipulate your database, model-based validations won&#39;t be in effect, and therefore won&#39;t be applied. This is why you design your schema to avoid invalid data wherever possible.</p></div><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated May 8, 2025</em></p><p>None at this time</p>`,47)]))}const g=a(n,[["render",l]]);export{c as __pageData,g as default};
+<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">end</span></span></code></pre></div><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><h3 id="do-not-put-business-logic-on-your-database-models" tabindex="-1">Do Not Put Business Logic On Your Database Models <a class="header-anchor" href="#do-not-put-business-logic-on-your-database-models" aria-label="Permalink to &quot;Do Not Put Business Logic On Your Database Models&quot;">​</a></h3><p>There&#39;s no reason to, or benefit to doing so. What you&#39;ll find is that any app of even moderate complexity will not have a strict mapping from page to business concept to database table. Rather, these things will all differ greatly, and each serves a different purpose.</p><p>The job of your data models—and the tables they provide access to—is to store reliable and unambiguous data. Their job is to ensure there is no bad data such that when you ask the database a question, you get a reliable and correct answer.</p><p>Your views and business logic do not have this exact same job.</p><p>As such, your models should only contain:</p><ul><li>configuration to allow navigating the database.</li><li>methods to manage type conversions between your types and the strings or numbers required in the database</li><li>methods to query the data based on data definitions (not business logic).</li></ul><p>Business logic and data models <em>do</em> overlap at times, so there is some judgement in maintaining a clear separation of concerns. One way to manage this is to always put all logic elsewhere until you see a pattern of re-use that leads you to extract that logic to a data model.</p><h3 id="do-not-use-validations-on-models-unless-there-is-no-other-choice" tabindex="-1">Do Not Use Validations on Models Unless There is No Other Choice <a class="header-anchor" href="#do-not-use-validations-on-models-unless-there-is-no-other-choice" aria-label="Permalink to &quot;Do Not Use Validations on Models Unless There is No Other Choice&quot;">​</a></h3><p>Sequel provides a validation layer for use on models. You should not generally use this, since a) data integrity is baked into your database design, and b) user interactions and constraints are part of the front-end.</p><p>That said, there are times when you have data constraints that cannot be modeled in the database. In that case, a validation on the data model is better than nothing. Since all data access for your app should go through your data models, a validation on a data model has a high chance of being checked.</p><div class="note custom-block github-alert"><p class="custom-block-title">NOTE</p><p>Since any process, app, or tool can manipulate your database, model-based validations won&#39;t be in effect, and therefore won&#39;t be applied. This is why you design your schema to avoid invalid data wherever possible.</p></div><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated May 8, 2025</em></p><p>None at this time</p>`,47)])])}const g=a(n,[["render",l]]);export{c as __pageData,g as default};

data/docs/assets/database-access.md.Dc8l2Plf.lean.js

@@ -0,0 +1 @@
+import{_ as a,c as i,o as e,ag as t}from"./chunks/framework.C4nOkCZI.js";const c=JSON.parse('{"title":"Database Access / Data Models","description":"","frontmatter":{},"headers":[],"relativePath":"database-access.md","filePath":"database-access.md"}'),n={name:"database-access.md"};function l(h,s,p,o,d,k){return e(),i("div",null,[...s[0]||(s[0]=[t("",47)])])}const g=a(n,[["render",l]]);export{c as __pageData,g as default};

data/docs/assets/{database-schema.md.LpmBPVEU.js → database-schema.md.BJ_JhXmO.js}

@@ -1,4 +1,4 @@
-import{_ as e,c as a,o as i,ag as t}from"./chunks/framework.1L-BeKqY.js";const u=JSON.parse('{"title":"Database Schema / Migrations","description":"","frontmatter":{},"headers":[],"relativePath":"database-schema.md","filePath":"database-schema.md"}'),n={name:"database-schema.md"};function l(o,s,r,h,p,d){return i(),a("div",null,s[0]||(s[0]=[t(`<h1 id="database-schema-migrations" tabindex="-1">Database Schema / Migrations <a class="header-anchor" href="#database-schema-migrations" aria-label="Permalink to &quot;Database Schema / Migrations&quot;">​</a></h1><p>Brut provides access to the database via the <a href="https://sequel.jeremyevans.net/" target="_blank" rel="noreferrer">Sequel library</a>. To manage your database schema, Brut uses Sequel&#39;s facility for this, with some of its own enhancements.</p><div class="note custom-block github-alert"><p class="custom-block-title">NOTE</p><p>Brut currently only supports Postgres. Sequel supports many database systems, however Brut&#39;s extensions are currently geared toward Postgres only.</p></div><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Your database schema is managed by a series of changes that build upon one another called <em>migrations</em>.</p><p>For example, if you have a table <code>widgets</code> that has a <code>name</code> and <code>description</code>, to add a <code>status</code> field, you cannot <code>drop table widgets</code> and then <code>create table widgets(...)</code> with the fields. You must instead <code>alter table widgets(...)</code> to add the new column.</p><p>Thus, each migration file is a change to the schema produced by all previous migration files.</p><p>Brut&#39;s provides this via Sequel. See <a href="https://sequel.jeremyevans.net/rdoc/files/doc/schema_modification_rdoc.html" target="_blank" rel="noreferrer">both</a> <a href="https://sequel.jeremyevans.net/rdoc/files/doc/migration_rdoc.html" target="_blank" rel="noreferrer">docs</a> for details on the API. Any schema modification method Sequel documents is available, however some default behavior has changed.</p><h3 id="creating-migrations" tabindex="-1">Creating Migrations <a class="header-anchor" href="#creating-migrations" aria-label="Permalink to &quot;Creating Migrations&quot;">​</a></h3><p>To create a migration, use <code>bin/db new-migration</code>. It accepts any number of arguments that will be joined together to form the filename:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>&gt; bin/db new-migration user accounts</span></span>
+import{_ as e,c as a,o as i,ag as t}from"./chunks/framework.C4nOkCZI.js";const u=JSON.parse('{"title":"Database Schema / Migrations","description":"","frontmatter":{},"headers":[],"relativePath":"database-schema.md","filePath":"database-schema.md"}'),n={name:"database-schema.md"};function l(o,s,r,h,p,d){return i(),a("div",null,[...s[0]||(s[0]=[t(`<h1 id="database-schema-migrations" tabindex="-1">Database Schema / Migrations <a class="header-anchor" href="#database-schema-migrations" aria-label="Permalink to &quot;Database Schema / Migrations&quot;">​</a></h1><p>Brut provides access to the database via the <a href="https://sequel.jeremyevans.net/" target="_blank" rel="noreferrer">Sequel library</a>. To manage your database schema, Brut uses Sequel&#39;s facility for this, with some of its own enhancements.</p><div class="note custom-block github-alert"><p class="custom-block-title">NOTE</p><p>Brut currently only supports Postgres. Sequel supports many database systems, however Brut&#39;s extensions are currently geared toward Postgres only.</p></div><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Your database schema is managed by a series of changes that build upon one another called <em>migrations</em>.</p><p>For example, if you have a table <code>widgets</code> that has a <code>name</code> and <code>description</code>, to add a <code>status</code> field, you cannot <code>drop table widgets</code> and then <code>create table widgets(...)</code> with the fields. You must instead <code>alter table widgets(...)</code> to add the new column.</p><p>Thus, each migration file is a change to the schema produced by all previous migration files.</p><p>Brut&#39;s provides this via Sequel. See <a href="https://sequel.jeremyevans.net/rdoc/files/doc/schema_modification_rdoc.html" target="_blank" rel="noreferrer">both</a> <a href="https://sequel.jeremyevans.net/rdoc/files/doc/migration_rdoc.html" target="_blank" rel="noreferrer">docs</a> for details on the API. Any schema modification method Sequel documents is available, however some default behavior has changed.</p><h3 id="creating-migrations" tabindex="-1">Creating Migrations <a class="header-anchor" href="#creating-migrations" aria-label="Permalink to &quot;Creating Migrations&quot;">​</a></h3><p>To create a migration, use <code>bin/db new-migration</code>. It accepts any number of arguments that will be joined together to form the filename:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>&gt; bin/db new-migration user accounts</span></span>
 <span class="line"><span>[ bin/db ] Migration created:</span></span>
 <span class="line"><span>    app/src/back_end/data_models/migrations/20250508132646_user-accounts.rb</span></span></code></pre></div><p>If you will be creating <a href="/database-access.html">database models</a> as well, you may find it easier to use <code>bin/scaffold db_model</code>, which will create an empty database model class, empty test, and empty factory, along with an outline of your migration:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>bin/scaffold db_model widget</span></span>
 <span class="line"><span>[ bin/scaffold ] Executing [&quot;bin/db new_migration create_widget&quot;]</span></span>
@@ -67,4 +67,4 @@ import{_ as e,c as a,o as i,ag as t}from"./chunks/framework.1L-BeKqY.js";const u
 <span class="line"><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">      setweight(to_tsvector(&#39;english&#39;, coalesce(description,&#39;&#39;)),&#39;B&#39;)</span></span>
 <span class="line"><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">    )</span></span>
 <span class="line"><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">  }</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">),</span></span>
-<span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">  generated_type:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> :stored</span></span></code></pre></div><p>If you are using Postgtes, why <em>not</em> use its features? Unless your app is database-agnostic, you should be using the features of your database, even if they aren&#39;t explicitly exposed via Sequel&#39;s Ruby API (that&#39;s why <code>Sequel.lit</code> exists).</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated May 8, 2025</em></p><p>As mentioned, Brut uses Sequel under the covers. This is unlikely to change.</p><p>As also mentioned, Brut&#39;s extensions often rely on Postgres. While we can all dream of a world where every developer uses the same database server, we don&#39;t live in that world. Brut should, some day, support all the databases that Sequel supports. For now, however, it only supports Postgres.</p><p>This hard-coded support is due to:</p><ul><li><code>pg_array</code></li><li><code>pg_json</code></li><li>Reliance on <code>citext</code> and <code>comment</code></li><li>Reliance on <code>timestamptz</code></li></ul><p>Brut is likely to add more Postgres-specific features before adding support for other databases.</p>`,70)]))}const k=e(n,[["render",l]]);export{u as __pageData,k as default};
+<span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">  generated_type:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> :stored</span></span></code></pre></div><p>If you are using Postgtes, why <em>not</em> use its features? Unless your app is database-agnostic, you should be using the features of your database, even if they aren&#39;t explicitly exposed via Sequel&#39;s Ruby API (that&#39;s why <code>Sequel.lit</code> exists).</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated May 8, 2025</em></p><p>As mentioned, Brut uses Sequel under the covers. This is unlikely to change.</p><p>As also mentioned, Brut&#39;s extensions often rely on Postgres. While we can all dream of a world where every developer uses the same database server, we don&#39;t live in that world. Brut should, some day, support all the databases that Sequel supports. For now, however, it only supports Postgres.</p><p>This hard-coded support is due to:</p><ul><li><code>pg_array</code></li><li><code>pg_json</code></li><li>Reliance on <code>citext</code> and <code>comment</code></li><li>Reliance on <code>timestamptz</code></li></ul><p>Brut is likely to add more Postgres-specific features before adding support for other databases.</p>`,70)])])}const k=e(n,[["render",l]]);export{u as __pageData,k as default};

data/docs/assets/database-schema.md.BJ_JhXmO.lean.js

@@ -0,0 +1 @@
+import{_ as e,c as a,o as i,ag as t}from"./chunks/framework.C4nOkCZI.js";const u=JSON.parse('{"title":"Database Schema / Migrations","description":"","frontmatter":{},"headers":[],"relativePath":"database-schema.md","filePath":"database-schema.md"}'),n={name:"database-schema.md"};function l(o,s,r,h,p,d){return i(),a("div",null,[...s[0]||(s[0]=[t("",70)])])}const k=e(n,[["render",l]]);export{u as __pageData,k as default};

data/docs/assets/{deployment.md.BLseERGV.js → deployment.md.C1u5ep0g.js}

@@ -1,4 +1,4 @@
-import{_ as a,c as n,o as s,ag as o}from"./chunks/framework.1L-BeKqY.js";const h=JSON.parse('{"title":"Deployment","description":"","frontmatter":{},"headers":[],"relativePath":"deployment.md","filePath":"deployment.md"}'),t={name:"deployment.md"};function l(p,e,i,r,d,c){return s(),n("div",null,e[0]||(e[0]=[o(`<h1 id="deployment" tabindex="-1">Deployment <a class="header-anchor" href="#deployment" aria-label="Permalink to &quot;Deployment&quot;">​</a></h1><p>Brut apps are Rack apps, so they can be deployed in conventional ways.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>There are just too many ways to deploy. Brut attempts to address this by adhering to <a href="https://12factor.net" target="_blank" rel="noreferrer">12-factor principles</a>. Brut also tries not to create artifacts like <code>Procfile</code> or <code>Dockerfile</code> that would conflict with the artifacts you&#39;d need to manage deployment.</p><p>That said, Brut includes first-class support for deploying to Heroku using containers. More options will be included as necessary, either through direct support in code/tooling, or documentation here.</p><h3 id="heroku-container-based-deployment" tabindex="-1">Heroku Container-based Deployment <a class="header-anchor" href="#heroku-container-based-deployment" aria-label="Permalink to &quot;Heroku Container-based Deployment&quot;">​</a></h3><p>When creating your Brut app with <code>mkbrut</code>, the Heroku segment can be used to create files and scripts for a <a href="https://devcenter.heroku.com/articles/container-registry-and-runtime" target="_blank" rel="noreferrer">Heroku container-based deployment</a>.</p><table tabindex="0"><thead><tr><th>File</th><th>Purpose</th><th>Notes</th></tr></thead><tbody><tr><td><code>bin/deploy</code></td><td>Script to use to perform the deployment</td><td>This wraps <code>HerokuContainerBasedDeploy</code> in <a href="/api/Brut/CLI/Apps.html" target="_self" rel="noopener" data-no-router><code>Brut::CLI::Apps</code></a></td></tr><tr><td><code>deploy/Dockerfile</code></td><td>Template <code>Dockerfile</code> used to create a <code>Dockerfile</code> for each process type</td><td>Heroku requires each process (web, worker, release, etc.) to have its own <code>Dockerfile</code> and own image</td></tr><tr><td><code>deploy/heroku_config.rb</code></td><td>Class that exports optional processes</td><td>By default, your app has a web and release process. <code>HerokuConfig</code> can export others, like Sidekiq</td></tr><tr><td><code>deploy/docker-entrypoint</code></td><td>The <a href="https://docs.docker.com/reference/dockerfile/#entrypoint" target="_blank" rel="noreferrer"><code>ENTRYPOINT</code></a> for production Docker images, which is set up to use jemalloc</td><td>You can modify or remove this as needed</td></tr></tbody></table><p>How to deploy:</p><ol><li><p>Auth to Heroku from inside your dev container:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>your-computer&gt; dx/exec bash</span></span>
+import{_ as a,c as n,o as s,ag as o}from"./chunks/framework.C4nOkCZI.js";const h=JSON.parse('{"title":"Deployment","description":"","frontmatter":{},"headers":[],"relativePath":"deployment.md","filePath":"deployment.md"}'),t={name:"deployment.md"};function l(p,e,i,r,d,c){return s(),n("div",null,[...e[0]||(e[0]=[o(`<h1 id="deployment" tabindex="-1">Deployment <a class="header-anchor" href="#deployment" aria-label="Permalink to &quot;Deployment&quot;">​</a></h1><p>Brut apps are Rack apps, so they can be deployed in conventional ways.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>There are just too many ways to deploy. Brut attempts to address this by adhering to <a href="https://12factor.net" target="_blank" rel="noreferrer">12-factor principles</a>. Brut also tries not to create artifacts like <code>Procfile</code> or <code>Dockerfile</code> that would conflict with the artifacts you&#39;d need to manage deployment.</p><p>That said, Brut includes first-class support for deploying to Heroku using containers. More options will be included as necessary, either through direct support in code/tooling, or documentation here.</p><h3 id="heroku-container-based-deployment" tabindex="-1">Heroku Container-based Deployment <a class="header-anchor" href="#heroku-container-based-deployment" aria-label="Permalink to &quot;Heroku Container-based Deployment&quot;">​</a></h3><p>When creating your Brut app with <code>mkbrut</code>, the Heroku segment can be used to create files and scripts for a <a href="https://devcenter.heroku.com/articles/container-registry-and-runtime" target="_blank" rel="noreferrer">Heroku container-based deployment</a>.</p><table tabindex="0"><thead><tr><th>File</th><th>Purpose</th><th>Notes</th></tr></thead><tbody><tr><td><code>bin/deploy</code></td><td>Script to use to perform the deployment</td><td>This wraps <code>HerokuContainerBasedDeploy</code> in <a href="/api/Brut/CLI/Apps.html" target="_self" rel="noopener" data-no-router><code>Brut::CLI::Apps</code></a></td></tr><tr><td><code>deploy/Dockerfile</code></td><td>Template <code>Dockerfile</code> used to create a <code>Dockerfile</code> for each process type</td><td>Heroku requires each process (web, worker, release, etc.) to have its own <code>Dockerfile</code> and own image</td></tr><tr><td><code>deploy/heroku_config.rb</code></td><td>Class that exports optional processes</td><td>By default, your app has a web and release process. <code>HerokuConfig</code> can export others, like Sidekiq</td></tr><tr><td><code>deploy/docker-entrypoint</code></td><td>The <a href="https://docs.docker.com/reference/dockerfile/#entrypoint" target="_blank" rel="noreferrer"><code>ENTRYPOINT</code></a> for production Docker images, which is set up to use jemalloc</td><td>You can modify or remove this as needed</td></tr></tbody></table><p>How to deploy:</p><ol><li><p>Auth to Heroku from inside your dev container:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>your-computer&gt; dx/exec bash</span></span>
 <span class="line"><span>devcontainer&gt; heroku auth:login</span></span>
 <span class="line"><span># You will need to copy/paste the URL to log in</span></span>
 <span class="line"><span>devcontainer&gt; heroku container:login</span></span></code></pre></div></li><li><p>Create your app using the container stack:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>&gt; heroku create --stack container -a «your heroku app name»</span></span></code></pre></div></li><li><p>Ensure your app&#39;s source code is all checked in, there are no uncommitted or unadded files, and you have pushed to main.</p></li><li><p><code>bin/deploy</code></p><p>This will generate a <code>Dockerfile</code> for each process (by default, <code>Dockerfile.web</code> and <code>Dockerfile.release</code>), build images, push those images to Heroku, and ask Heroku to release them.</p></li></ol><p>Debugging Tips:</p><ul><li><p>Keep in mind it&#39;s hard to make general deployment tools. You are expected to understand your deployment and be capable of deploying an arbitrary Rack app manually. Brut&#39;s tooling automates what you need to know.</p></li><li><p><code>bin/deploy</code> runs the <code>deploy</code> subcommand, so <code>bin/deploy help deploy</code> can provide some options for debugging issues:</p><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>devcontainer&gt; bin/deploy help deploy</span></span>
@@ -45,4 +45,4 @@ import{_ as a,c as n,o as s,ag as o}from"./chunks/framework.1L-BeKqY.js";const h
 <span class="line"><span>        --[no-]deploy        After images are pushed, actually deploy them</span></span>
 <span class="line"><span>        --[no-]push          After images are created, push them</span></span>
 <span class="line"><span>                             to Heroku&#39;s registry. If false,</span></span>
-<span class="line"><span>                             implies --no-deploy</span></span></code></pre></div></li><li><p>Try building images first: <code>bin/deploy deploy --no-push --skip-checks</code></p></li><li><p>It&#39;s possible to run the images locally. If you are on Apple Silicon, you&#39;ll need to set --platform:</p><ul><li><code>bin/deploy deploy --no-push --skip-checks --platform linux/arm64</code></li><li>Create <code>docker-compose.yml</code> for your image and any other services e.g. databases</li><li>Set required environment variables in <code>docker-compose.yml</code></li><li>Start up Docker compose and poke around</li></ul><p>You&#39;ll need to have a better understanding of Docker to do this, however if you are deploying with Docker, this is an understanding you hopefully already have.</p></li></ul><h3 id="other-mechanisms-for-deployment" tabindex="-1">Other Mechanisms for Deployment <a class="header-anchor" href="#other-mechanisms-for-deployment" aria-label="Permalink to &quot;Other Mechanisms for Deployment&quot;">​</a></h3><p>As a Rack app, other deployments should be possible. To make the app work, you&#39;ll need to make sure a few things are dealt with:</p><ul><li><code>RACK_ENV</code> <strong>must</strong> be <code>&quot;production&quot;</code></li><li><code>bin/build-assets</code> will build all assets by default. This must either be done on production servers or done ahead of time and the results packaged with the app.</li><li><code>bin/build-assets</code> outputs files in <code>app/public</code> and <code>app/config</code>. Those files are used at runtime. Brut <strong>will not</strong> initiate the build of any assets.</li><li>If you are going to build assets on production servers, you <em>must</em> included developer tooling. This means NodeJS, all modules in <code>package.json</code> and all RubyGems in <code>Gemfile</code>.</li></ul><p>The <code>deploy/Dockerfile</code> created by <code>mkbrut --segment-heroku</code> is not very Heroku-specific and could serve as a reference.</p><h2 id="testing" tabindex="-1">Testing <a class="header-anchor" href="#testing" aria-label="Permalink to &quot;Testing&quot;">​</a></h2><p>Testing deployments is a bit out of scope, but in general:</p><ul><li>A container-based deployment can theoretically be run on your computer as a test.</li><li>Non-production, but production-like environments can be used to validate production configurations.</li><li>You own the means of production…not Brut.</li></ul><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><ul><li>Avoid a lot of code that checks <code>Brut.container.project_env</code>. Try to consolidate all prod/test/dev differences in environment variables.</li><li>Have a way to get a shell into your production environment for debugging.</li><li>Brut doesn&#39;t log much, but if you remove the <code>OTEL_*</code> environment variables, Brut will log OTel telemetry to the console, which may be useful.</li><li>Setting <code>OTEL_LOG_LEVEL=debug</code> is advised if the app isn&#39;t starting or you aren&#39;t seeing any telemetry or logging</li></ul><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated July 3, 2025</em></p><p>None at this time.</p>`,25)]))}const m=a(t,[["render",l]]);export{h as __pageData,m as default};
+<span class="line"><span>                             implies --no-deploy</span></span></code></pre></div></li><li><p>Try building images first: <code>bin/deploy deploy --no-push --skip-checks</code></p></li><li><p>It&#39;s possible to run the images locally. If you are on Apple Silicon, you&#39;ll need to set --platform:</p><ul><li><code>bin/deploy deploy --no-push --skip-checks --platform linux/arm64</code></li><li>Create <code>docker-compose.yml</code> for your image and any other services e.g. databases</li><li>Set required environment variables in <code>docker-compose.yml</code></li><li>Start up Docker compose and poke around</li></ul><p>You&#39;ll need to have a better understanding of Docker to do this, however if you are deploying with Docker, this is an understanding you hopefully already have.</p></li></ul><h3 id="other-mechanisms-for-deployment" tabindex="-1">Other Mechanisms for Deployment <a class="header-anchor" href="#other-mechanisms-for-deployment" aria-label="Permalink to &quot;Other Mechanisms for Deployment&quot;">​</a></h3><p>As a Rack app, other deployments should be possible. To make the app work, you&#39;ll need to make sure a few things are dealt with:</p><ul><li><code>RACK_ENV</code> <strong>must</strong> be <code>&quot;production&quot;</code></li><li><code>bin/build-assets</code> will build all assets by default. This must either be done on production servers or done ahead of time and the results packaged with the app.</li><li><code>bin/build-assets</code> outputs files in <code>app/public</code> and <code>app/config</code>. Those files are used at runtime. Brut <strong>will not</strong> initiate the build of any assets.</li><li>If you are going to build assets on production servers, you <em>must</em> included developer tooling. This means NodeJS, all modules in <code>package.json</code> and all RubyGems in <code>Gemfile</code>.</li></ul><p>The <code>deploy/Dockerfile</code> created by <code>mkbrut --segment-heroku</code> is not very Heroku-specific and could serve as a reference.</p><h2 id="testing" tabindex="-1">Testing <a class="header-anchor" href="#testing" aria-label="Permalink to &quot;Testing&quot;">​</a></h2><p>Testing deployments is a bit out of scope, but in general:</p><ul><li>A container-based deployment can theoretically be run on your computer as a test.</li><li>Non-production, but production-like environments can be used to validate production configurations.</li><li>You own the means of production…not Brut.</li></ul><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><ul><li>Avoid a lot of code that checks <code>Brut.container.project_env</code>. Try to consolidate all prod/test/dev differences in environment variables.</li><li>Have a way to get a shell into your production environment for debugging.</li><li>Brut doesn&#39;t log much, but if you remove the <code>OTEL_*</code> environment variables, Brut will log OTel telemetry to the console, which may be useful.</li><li>Setting <code>OTEL_LOG_LEVEL=debug</code> is advised if the app isn&#39;t starting or you aren&#39;t seeing any telemetry or logging</li></ul><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated July 3, 2025</em></p><p>None at this time.</p>`,25)])])}const m=a(t,[["render",l]]);export{h as __pageData,m as default};

data/docs/assets/deployment.md.C1u5ep0g.lean.js

@@ -0,0 +1 @@
+import{_ as a,c as n,o as s,ag as o}from"./chunks/framework.C4nOkCZI.js";const h=JSON.parse('{"title":"Deployment","description":"","frontmatter":{},"headers":[],"relativePath":"deployment.md","filePath":"deployment.md"}'),t={name:"deployment.md"};function l(p,e,i,r,d,c){return s(),n("div",null,[...e[0]||(e[0]=[o("",25)])])}const m=a(t,[["render",l]]);export{h as __pageData,m as default};

data/docs/assets/{dev-environment.md.DRH2D2-O.js → dev-environment.md.B1S9p5ZK.js}

@@ -1,4 +1,4 @@
-import{_ as t,c as a,o,ag as s}from"./chunks/framework.1L-BeKqY.js";const i="/assets/DevEnvironment.DaFcVfwP.png",n="/assets/dev-env-protocol.DysDAtnz.png",d="/assets/workspace-protocol.C0gXsoDb.png",g=JSON.parse('{"title":"Dev Environment","description":"","frontmatter":{},"headers":[],"relativePath":"dev-environment.md","filePath":"dev-environment.md"}'),r={name:"dev-environment.md"};function l(c,e,p,h,u,m){return o(),a("div",null,e[0]||(e[0]=[s('<h1 id="dev-environment" tabindex="-1">Dev Environment <a class="header-anchor" href="#dev-environment" aria-label="Permalink to &quot;Dev Environment&quot;">​</a></h1><p>Brut provides sophisticated tooling to manage your dev environment</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>A development environments or <em>dev environment</em> is made up of two parts:</p><ul><li><em>Foundational Core</em> - the operating system and tools needed to run the app and <em>its</em> tools. This includes language runtimes, system libraries (like ImageMagick), and system tools like web browsers.</li><li><em>Workspace</em> - the tools and code bundled with the app that you use day-to-day to work on the app itself. This would include scripts to run the app in development, run tests, perform scaffolding, or manage the database.</li></ul><p>On many teams, the Foundational Core is different per developer, since some run Linux, some run MacOs. Some might use mise to manage their version of Ruby while others use rbenv. Some will set up Postgres via homebrew, while others might use Popstgres.app.</p><p>Brut takes a different approach. Everyone shares the same Foundational Core, and this is defined by a <code>Dockerfile</code>, a <code>docker-compose.yml</code> file, and some lightweight Bash scripts.</p><p>This means that everyone uses the same version of everything, and they are all managed the same way.</p><p>Brut also provides sophisticated tooling for the Workspace. Like Rails, Brut provides a command-line based flow that can be scripted into any editor. Unlike Rails, Brut&#39;s Workspace is comprised of separate command-line apps and not Rake tasks.</p><h3 id="conceptual-overview" tabindex="-1">Conceptual Overview <a class="header-anchor" href="#conceptual-overview" aria-label="Permalink to &quot;Conceptual Overview&quot;">​</a></h3><p>Your dev environment consists of a Docker container that has languages, an operating system, and other system components installed in it. It will have access to the files on your computer so that it can run your app. The app will be exposed so that a browser on your computer can access it. Postgres will be run as a separate Docker container available to the dev Docker container.</p><p>Your editor and version control system run on your computer.</p><p><img src="'+i+`" alt="Diagram showing the parts of the dev environment. The foundational core is also
+import{_ as t,c as a,o,ag as s}from"./chunks/framework.C4nOkCZI.js";const i="/assets/DevEnvironment.DaFcVfwP.png",n="/assets/dev-env-protocol.DysDAtnz.png",d="/assets/workspace-protocol.C0gXsoDb.png",g=JSON.parse('{"title":"Dev Environment","description":"","frontmatter":{},"headers":[],"relativePath":"dev-environment.md","filePath":"dev-environment.md"}'),r={name:"dev-environment.md"};function l(c,e,p,h,u,m){return o(),a("div",null,[...e[0]||(e[0]=[s('<h1 id="dev-environment" tabindex="-1">Dev Environment <a class="header-anchor" href="#dev-environment" aria-label="Permalink to &quot;Dev Environment&quot;">​</a></h1><p>Brut provides sophisticated tooling to manage your dev environment</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>A development environments or <em>dev environment</em> is made up of two parts:</p><ul><li><em>Foundational Core</em> - the operating system and tools needed to run the app and <em>its</em> tools. This includes language runtimes, system libraries (like ImageMagick), and system tools like web browsers.</li><li><em>Workspace</em> - the tools and code bundled with the app that you use day-to-day to work on the app itself. This would include scripts to run the app in development, run tests, perform scaffolding, or manage the database.</li></ul><p>On many teams, the Foundational Core is different per developer, since some run Linux, some run MacOs. Some might use mise to manage their version of Ruby while others use rbenv. Some will set up Postgres via homebrew, while others might use Popstgres.app.</p><p>Brut takes a different approach. Everyone shares the same Foundational Core, and this is defined by a <code>Dockerfile</code>, a <code>docker-compose.yml</code> file, and some lightweight Bash scripts.</p><p>This means that everyone uses the same version of everything, and they are all managed the same way.</p><p>Brut also provides sophisticated tooling for the Workspace. Like Rails, Brut provides a command-line based flow that can be scripted into any editor. Unlike Rails, Brut&#39;s Workspace is comprised of separate command-line apps and not Rake tasks.</p><h3 id="conceptual-overview" tabindex="-1">Conceptual Overview <a class="header-anchor" href="#conceptual-overview" aria-label="Permalink to &quot;Conceptual Overview&quot;">​</a></h3><p>Your dev environment consists of a Docker container that has languages, an operating system, and other system components installed in it. It will have access to the files on your computer so that it can run your app. The app will be exposed so that a browser on your computer can access it. Postgres will be run as a separate Docker container available to the dev Docker container.</p><p>Your editor and version control system run on your computer.</p><p><img src="'+i+`" alt="Diagram showing the parts of the dev environment. The foundational core is also
 labeled &quot;Docker containers&quot; and it contains three boxes labeled &quot;Container&quot;.  One
 box contains ValKey, another contains Postrgres. The third box contains &quot;Your Brut
 App&quot;, &quot;NodeJS&quot;, &quot;Ruby&quot;, and part of &quot;Source Code&quot;. The &quot;Source Code&quot; also also
@@ -13,4 +13,4 @@ This box contains &quot;Browser&quot; and &quot;source code editor&quot;."></p><
 <span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">exit</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> Brut</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">CLI</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">app</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span></span>
 <span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">       Brut</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">CLI</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">Apps</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">DB</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">,</span></span>
 <span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">       project_root:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> Pathname</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">($0).</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">dirname</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> /</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;..&quot;</span></span>
-<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">     )</span></span></code></pre></div><p>These files have some duplication, but should be relatively stable.</p><p>This means that Brut-provided CLIs <em>will</em> be updated when you update Brut. Compare this to the files in <code>dx/</code> which are entire Bash scripts that will not be updated when Brut is updated.</p>`,48)]))}const b=t(r,[["render",l]]);export{g as __pageData,b as default};
+<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">     )</span></span></code></pre></div><p>These files have some duplication, but should be relatively stable.</p><p>This means that Brut-provided CLIs <em>will</em> be updated when you update Brut. Compare this to the files in <code>dx/</code> which are entire Bash scripts that will not be updated when Brut is updated.</p>`,48)])])}const b=t(r,[["render",l]]);export{g as __pageData,b as default};

data/docs/assets/{dev-environment.md.DRH2D2-O.lean.js → dev-environment.md.B1S9p5ZK.lean.js}

@@ -1 +1 @@
-import{_ as t,c as a,o,ag as s}from"./chunks/framework.1L-BeKqY.js";const i="/assets/DevEnvironment.DaFcVfwP.png",n="/assets/dev-env-protocol.DysDAtnz.png",d="/assets/workspace-protocol.C0gXsoDb.png",g=JSON.parse('{"title":"Dev Environment","description":"","frontmatter":{},"headers":[],"relativePath":"dev-environment.md","filePath":"dev-environment.md"}'),r={name:"dev-environment.md"};function l(c,e,p,h,u,m){return o(),a("div",null,e[0]||(e[0]=[s("",48)]))}const b=t(r,[["render",l]]);export{g as __pageData,b as default};
+import{_ as t,c as a,o,ag as s}from"./chunks/framework.C4nOkCZI.js";const i="/assets/DevEnvironment.DaFcVfwP.png",n="/assets/dev-env-protocol.DysDAtnz.png",d="/assets/workspace-protocol.C0gXsoDb.png",g=JSON.parse('{"title":"Dev Environment","description":"","frontmatter":{},"headers":[],"relativePath":"dev-environment.md","filePath":"dev-environment.md"}'),r={name:"dev-environment.md"};function l(c,e,p,h,u,m){return o(),a("div",null,[...e[0]||(e[0]=[s("",48)])])}const b=t(r,[["render",l]]);export{g as __pageData,b as default};

data/docs/assets/{dir-structure.md.CWir1pic.js → dir-structure.md.D1T2kGwj.js}

@@ -1,4 +1,4 @@
-import{_ as a,c as t,o as e,ag as n}from"./chunks/framework.1L-BeKqY.js";const h=JSON.parse('{"title":"Directory Structure","description":"","frontmatter":{},"headers":[],"relativePath":"dir-structure.md","filePath":"dir-structure.md"}'),d={name:"dir-structure.md"};function o(p,s,c,r,l,i){return e(),t("div",null,s[0]||(s[0]=[n(`<h1 id="directory-structure" tabindex="-1">Directory Structure <a class="header-anchor" href="#directory-structure" aria-label="Permalink to &quot;Directory Structure&quot;">​</a></h1><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>.</span></span>
+import{_ as a,c as t,o as e,ag as n}from"./chunks/framework.C4nOkCZI.js";const h=JSON.parse('{"title":"Directory Structure","description":"","frontmatter":{},"headers":[],"relativePath":"dir-structure.md","filePath":"dir-structure.md"}'),d={name:"dir-structure.md"};function o(p,s,c,r,l,i){return e(),t("div",null,[...s[0]||(s[0]=[n(`<h1 id="directory-structure" tabindex="-1">Directory Structure <a class="header-anchor" href="#directory-structure" aria-label="Permalink to &quot;Directory Structure&quot;">​</a></h1><div class="language- vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang"></span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span>.</span></span>
 <span class="line"><span>├── app</span></span>
 <span class="line"><span>│   ├── config</span></span>
 <span class="line"><span>│   │   └── i18n</span></span>
@@ -43,4 +43,4 @@ import{_ as a,c as t,o as e,ag as n}from"./chunks/framework.1L-BeKqY.js";const h
 <span class="line"><span>        ├── handlers</span></span>
 <span class="line"><span>        ├── js</span></span>
 <span class="line"><span>        ├── pages</span></span>
-<span class="line"><span>        └── support</span></span></code></pre></div><h2 id="top-level" tabindex="-1">Top Level <a class="header-anchor" href="#top-level" aria-label="Permalink to &quot;Top Level&quot;">​</a></h2><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>app/</code></td><td>Contains all configuration and source code specific to your app</td></tr><tr><td><code>bin/</code></td><td>Contains tasks and other CLIs to do development of your app, such as <code>bin/test</code></td></tr><tr><td><code>dx/</code></td><td>Contains scripts to manage your development environment</td></tr><tr><td><code>specs/</code></td><td>Contains all tests</td></tr></tbody></table><h2 id="inside-app" tabindex="-1">Inside <code>app</code>/ <a class="header-anchor" href="#inside-app" aria-label="Permalink to &quot;Inside \`app\`/&quot;">​</a></h2><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>bootstrap.rb</code></td><td>A ruby file that sets up your app and ensures everything is <code>require</code>d in the right way.</td></tr><tr><td><code>config/</code></td><td>Configuration for your app, such as localizations and translations. Brut tries very hard to make sure there is no YAML in here at all. YAML is not good for you.</td></tr><tr><td><code>public/</code></td><td>Root of public assets served by the app.</td></tr><tr><td><code>src/</code></td><td>All source code for your app</td></tr></tbody></table><p>Inside <code>app/src</code></p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>app.rb</code></td><td>The core of your app, mostly configuration, such as routes, hooks, middleware, etc.</td></tr><tr><td><code>back_end/</code></td><td>Back end classes for your app including database schema, DB models, seed data, and your domain logic</td></tr><tr><td><code>cli/</code></td><td>Any CLIs or tasks for your app</td></tr><tr><td><code>front_end/</code></td><td>The front-end for your app, including pages, components, forms, handlers, JavaScript, and assets</td></tr></tbody></table><p>Inside <code>app/src/back_end</code></p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>data_models/app_data_model.rb</code></td><td>Base class for all DB model classes</td></tr><tr><td><code>data_models/db</code></td><td>DB model classes</td></tr><tr><td><code>data_models/db.rb</code></td><td>Namespace module for DB model classes</td></tr><tr><td><code>data_models/migrations</code></td><td>Database schema migrations</td></tr><tr><td><code>data_models/seed</code></td><td>Seed data used for local development</td></tr></tbody></table><p>Inside <code>app/src/front_end</code></p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>components/</code></td><td>Component classes</td></tr><tr><td><code>css/</code></td><td>CSS, managed by esbuild and <code>bin/build-assets</code></td></tr><tr><td><code>fonts/</code></td><td>Custom fonts, managed by esbuild and <code>bin/build-assets</code></td></tr><tr><td><code>forms/</code></td><td>Form classes</td></tr><tr><td><code>handlers/</code></td><td>Handler classes</td></tr><tr><td><code>images/</code></td><td>Images, copied to <code>app/public</code> by <code>bin/build-assets</code></td></tr><tr><td><code>js/</code></td><td>JavaScript, managed by esbuild and <code>bin/build-assets</code></td></tr><tr><td><code>layouts/</code></td><td>Layout classes</td></tr><tr><td><code>middlewares/</code></td><td>Rack Middleware, if any</td></tr><tr><td><code>pages/</code></td><td>Page classes</td></tr><tr><td><code>route_hooks/</code></td><td>Route hooks, if any</td></tr><tr><td><code>support/</code></td><td>General support classes/junk drawer.</td></tr><tr><td><code>svgs/</code></td><td>SVGs you want to render inline</td></tr></tbody></table><h2 id="inside-specs" tabindex="-1">Inside <code>specs/</code> <a class="header-anchor" href="#inside-specs" aria-label="Permalink to &quot;Inside \`specs/\`&quot;">​</a></h2><p><code>specs/</code> is intended to mirror <code>app/src</code>, but has a few extra directories:</p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>specs/back_end</code></td><td>tests for all back-end code, organized the same as <code>app/src/back_end</code></td></tr><tr><td><code>specs/back_end/data_models/db</code></td><td>tests for all DB classes, if needed</td></tr><tr><td><code>specs/e2e</code></td><td>End-to-end tests, organized however you like</td></tr><tr><td><code>specs/factories</code></td><td>Root of all factories for FactoryBot. You can create subdirectories here for non-DB classes you may want to be able to create</td></tr><tr><td><code>specs/factories/db</code></td><td>Factories to create DB records</td></tr><tr><td><code>specs/front_end</code></td><td>tests for all front-end code, organized the same as <code>app/src/front_end</code></td></tr><tr><td><code>specs/js</code></td><td><em>JavaScript</em> code to test any autonomous custom elements you have created</td></tr></tbody></table>`,15)]))}const b=a(d,[["render",o]]);export{h as __pageData,b as default};
+<span class="line"><span>        └── support</span></span></code></pre></div><h2 id="top-level" tabindex="-1">Top Level <a class="header-anchor" href="#top-level" aria-label="Permalink to &quot;Top Level&quot;">​</a></h2><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>app/</code></td><td>Contains all configuration and source code specific to your app</td></tr><tr><td><code>bin/</code></td><td>Contains tasks and other CLIs to do development of your app, such as <code>bin/test</code></td></tr><tr><td><code>dx/</code></td><td>Contains scripts to manage your development environment</td></tr><tr><td><code>specs/</code></td><td>Contains all tests</td></tr></tbody></table><h2 id="inside-app" tabindex="-1">Inside <code>app</code>/ <a class="header-anchor" href="#inside-app" aria-label="Permalink to &quot;Inside \`app\`/&quot;">​</a></h2><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>bootstrap.rb</code></td><td>A ruby file that sets up your app and ensures everything is <code>require</code>d in the right way.</td></tr><tr><td><code>config/</code></td><td>Configuration for your app, such as localizations and translations. Brut tries very hard to make sure there is no YAML in here at all. YAML is not good for you.</td></tr><tr><td><code>public/</code></td><td>Root of public assets served by the app.</td></tr><tr><td><code>src/</code></td><td>All source code for your app</td></tr></tbody></table><p>Inside <code>app/src</code></p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>app.rb</code></td><td>The core of your app, mostly configuration, such as routes, hooks, middleware, etc.</td></tr><tr><td><code>back_end/</code></td><td>Back end classes for your app including database schema, DB models, seed data, and your domain logic</td></tr><tr><td><code>cli/</code></td><td>Any CLIs or tasks for your app</td></tr><tr><td><code>front_end/</code></td><td>The front-end for your app, including pages, components, forms, handlers, JavaScript, and assets</td></tr></tbody></table><p>Inside <code>app/src/back_end</code></p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>data_models/app_data_model.rb</code></td><td>Base class for all DB model classes</td></tr><tr><td><code>data_models/db</code></td><td>DB model classes</td></tr><tr><td><code>data_models/db.rb</code></td><td>Namespace module for DB model classes</td></tr><tr><td><code>data_models/migrations</code></td><td>Database schema migrations</td></tr><tr><td><code>data_models/seed</code></td><td>Seed data used for local development</td></tr></tbody></table><p>Inside <code>app/src/front_end</code></p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>components/</code></td><td>Component classes</td></tr><tr><td><code>css/</code></td><td>CSS, managed by esbuild and <code>bin/build-assets</code></td></tr><tr><td><code>fonts/</code></td><td>Custom fonts, managed by esbuild and <code>bin/build-assets</code></td></tr><tr><td><code>forms/</code></td><td>Form classes</td></tr><tr><td><code>handlers/</code></td><td>Handler classes</td></tr><tr><td><code>images/</code></td><td>Images, copied to <code>app/public</code> by <code>bin/build-assets</code></td></tr><tr><td><code>js/</code></td><td>JavaScript, managed by esbuild and <code>bin/build-assets</code></td></tr><tr><td><code>layouts/</code></td><td>Layout classes</td></tr><tr><td><code>middlewares/</code></td><td>Rack Middleware, if any</td></tr><tr><td><code>pages/</code></td><td>Page classes</td></tr><tr><td><code>route_hooks/</code></td><td>Route hooks, if any</td></tr><tr><td><code>support/</code></td><td>General support classes/junk drawer.</td></tr><tr><td><code>svgs/</code></td><td>SVGs you want to render inline</td></tr></tbody></table><h2 id="inside-specs" tabindex="-1">Inside <code>specs/</code> <a class="header-anchor" href="#inside-specs" aria-label="Permalink to &quot;Inside \`specs/\`&quot;">​</a></h2><p><code>specs/</code> is intended to mirror <code>app/src</code>, but has a few extra directories:</p><table tabindex="0"><thead><tr><th>Directory</th><th>Purpose</th></tr></thead><tbody><tr><td><code>specs/back_end</code></td><td>tests for all back-end code, organized the same as <code>app/src/back_end</code></td></tr><tr><td><code>specs/back_end/data_models/db</code></td><td>tests for all DB classes, if needed</td></tr><tr><td><code>specs/e2e</code></td><td>End-to-end tests, organized however you like</td></tr><tr><td><code>specs/factories</code></td><td>Root of all factories for FactoryBot. You can create subdirectories here for non-DB classes you may want to be able to create</td></tr><tr><td><code>specs/factories/db</code></td><td>Factories to create DB records</td></tr><tr><td><code>specs/front_end</code></td><td>tests for all front-end code, organized the same as <code>app/src/front_end</code></td></tr><tr><td><code>specs/js</code></td><td><em>JavaScript</em> code to test any autonomous custom elements you have created</td></tr></tbody></table>`,15)])])}const b=a(d,[["render",o]]);export{h as __pageData,b as default};

data/docs/assets/dir-structure.md.D1T2kGwj.lean.js

@@ -0,0 +1 @@
+import{_ as a,c as t,o as e,ag as n}from"./chunks/framework.C4nOkCZI.js";const h=JSON.parse('{"title":"Directory Structure","description":"","frontmatter":{},"headers":[],"relativePath":"dir-structure.md","filePath":"dir-structure.md"}'),d={name:"dir-structure.md"};function o(p,s,c,r,l,i){return e(),t("div",null,[...s[0]||(s[0]=[n("",15)])])}const b=a(d,[["render",o]]);export{h as __pageData,b as default};

data/docs/assets/doc-conventions.md.CDnWaEFg.js

@@ -0,0 +1 @@
+import{_ as t,c as o,o as s,ag as r}from"./chunks/framework.C4nOkCZI.js";const m=JSON.parse('{"title":"Documentation Conventions","description":"","frontmatter":{},"headers":[],"relativePath":"doc-conventions.md","filePath":"doc-conventions.md"}'),n={name:"doc-conventions.md"};function a(i,e,l,u,c,d){return s(),o("div",null,[...e[0]||(e[0]=[r('<h1 id="documentation-conventions" tabindex="-1">Documentation Conventions <a class="header-anchor" href="#documentation-conventions" aria-label="Permalink to &quot;Documentation Conventions&quot;">​</a></h1><h2 id="terminology" tabindex="-1">Terminology <a class="header-anchor" href="#terminology" aria-label="Permalink to &quot;Terminology&quot;">​</a></h2><p>Brut attempts to use existing terminology where possible, particularly where that technology applies to the web platform. For example, there is not a thing called &quot;CSS variables&quot;, rather the term is &quot;custom properties&quot;.</p><p>Here are some common exampels:</p><ul><li>HTML entities are <strong>elements</strong> or <strong>tags</strong></li><li>HTML elements have <strong>attributes</strong>.</li><li>Forms don&#39;t have validations, they have <strong>constraints</strong> which are <strong>violated</strong> by invalid data.</li><li>Ruby classes don&#39;t have constructors, they have <strong>initializers</strong>.</li><li>Invoking behavior on a Ruby object is <strong>calling a method</strong>, not sending a message.</li><li>Despite being in <code>specs/</code>, the files in there are <strong>tests</strong>, not specifications or &quot;specs&quot;.</li><li>Tests that use a browser are <strong>end to end</strong> or <strong>e2e</strong> tests.</li><li>HTML is not rendered, but <strong>generated</strong>. The browser renders the HTML sent to it by the server, along with the CSS.</li><li>Your app or site doesn&#39;t have users, it has <strong>visitors</strong>.</li></ul><h2 id="structure-of-these-documents" tabindex="-1">Structure of These Documents <a class="header-anchor" href="#structure-of-these-documents" aria-label="Permalink to &quot;Structure of These Documents&quot;">​</a></h2><p>Each page here documents on aspect of Brut, called a <em>module</em>, and these pages are organized along four sections:</p><ul><li><strong>Overview</strong> - What the module does, how it works, and a brief example.</li><li><strong>Testing</strong> - How to test the code you write in this module.</li><li><strong>Recommended Practices</strong> - Opinions from the creators about how best to think about the code in this module.</li><li><strong>Technical Notes</strong> - details about the technical implementations that may be useful as context.</li></ul><h2 id="names-of-the-library-and-associated-modules" tabindex="-1">Names of the Library and Associated Modules <a class="header-anchor" href="#names-of-the-library-and-associated-modules" aria-label="Permalink to &quot;Names of the Library and Associated Modules&quot;">​</a></h2><p>This framework is called &quot;Brut&quot; though may be called &quot;BrutRB&quot; or &quot;brut-rp&quot;. It lives at <code>brutrb.com</code>. Never use &quot;brutRB&quot;, &quot;brut_rb&quot;, etc.</p><p>The JavaScript library is called &quot;BrutJS&quot;, but is <code>brut-js</code> in code or the filesystem. &quot;Brut-JS&quot; is wrong, as is <code>brut_js</code>.</p><p>The CSS library is called &quot;BrutCSS&quot;, but is <code>brut-css</code> in code or the filesystem. &quot;Brut-CSS&quot; is wrong, as is &quot;brut-css&quot;.</p><h2 id="on-using-vitepress" tabindex="-1">On Using VitePress <a class="header-anchor" href="#on-using-vitepress" aria-label="Permalink to &quot;On Using VitePress&quot;">​</a></h2><p>This site is built using <a href="https://vitepress.dev" target="_blank" rel="noreferrer">VitePress</a>, which is a client-side heavy framework. It kinda goes against the ethos of Brut, but it is allowing me to write documentation that looks decent and is mostly navigable. I would like to use a more accessible, customized system for documenting Brut, but for now, it&#39;s more important to get the documentation out. A better documentation experience is planned.</p>',14)])])}const g=t(n,[["render",a]]);export{m as __pageData,g as default};

data/docs/assets/doc-conventions.md.CDnWaEFg.lean.js

@@ -0,0 +1 @@
+import{_ as t,c as o,o as s,ag as r}from"./chunks/framework.C4nOkCZI.js";const m=JSON.parse('{"title":"Documentation Conventions","description":"","frontmatter":{},"headers":[],"relativePath":"doc-conventions.md","filePath":"doc-conventions.md"}'),n={name:"doc-conventions.md"};function a(i,e,l,u,c,d){return s(),o("div",null,[...e[0]||(e[0]=[r("",14)])])}const g=t(n,[["render",a]]);export{m as __pageData,g as default};

data/docs/assets/{end-to-end-tests.md.DzqRpZ43.js → end-to-end-tests.md.BJJdNDYL.js}

@@ -1,4 +1,4 @@
-import{_ as e,c as t,o as a,ag as i}from"./chunks/framework.1L-BeKqY.js";const k=JSON.parse('{"title":"End to End Tests","description":"","frontmatter":{},"headers":[],"relativePath":"end-to-end-tests.md","filePath":"end-to-end-tests.md"}'),n={name:"end-to-end-tests.md"};function o(l,s,h,r,p,d){return a(),t("div",null,s[0]||(s[0]=[i(`<h1 id="end-to-end-tests" tabindex="-1">End to End Tests <a class="header-anchor" href="#end-to-end-tests" aria-label="Permalink to &quot;End to End Tests&quot;">​</a></h1><p>Is there a greater pain the world than an end-to-end test? Is there a more punishing API than trying to convince a browser to browse and use a website? Is there an answer for why the way we interact with browsers when writing code is 100% different than the we do when writing a test?</p><p>Brut cannot answer these things, but it does provide a way to write end-to-end tests with a browser, with a somewhat slightly reduced amount of pain.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Brut uses <a href="https://playwright.dev/" target="_blank" rel="noreferrer">Playwright</a> and the <a href="https://playwright-ruby-client.vercel.app/" target="_blank" rel="noreferrer">playwright-ruby-client</a> to allow you to write end-to-end tests that use a web browser. Brut sets up headless Chromium to do this.</p><p>You can run End-to-End (e2e) tests with <code>bin/test e2e</code>. You must use this to run individual tests as well, since this will ensure proper set up for the tests, which is more than is needed for a normal unit test.</p><h3 id="using-playwright" tabindex="-1">Using Playwright <a class="header-anchor" href="#using-playwright" aria-label="Permalink to &quot;Using Playwright&quot;">​</a></h3><p>At a high level, e2e tests look like normal RSpec tests:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">require</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;spec_helper&quot;</span></span>
+import{_ as e,c as t,o as a,ag as i}from"./chunks/framework.C4nOkCZI.js";const k=JSON.parse('{"title":"End to End Tests","description":"","frontmatter":{},"headers":[],"relativePath":"end-to-end-tests.md","filePath":"end-to-end-tests.md"}'),n={name:"end-to-end-tests.md"};function o(l,s,h,r,p,d){return a(),t("div",null,[...s[0]||(s[0]=[i(`<h1 id="end-to-end-tests" tabindex="-1">End to End Tests <a class="header-anchor" href="#end-to-end-tests" aria-label="Permalink to &quot;End to End Tests&quot;">​</a></h1><p>Is there a greater pain the world than an end-to-end test? Is there a more punishing API than trying to convince a browser to browse and use a website? Is there an answer for why the way we interact with browsers when writing code is 100% different than the we do when writing a test?</p><p>Brut cannot answer these things, but it does provide a way to write end-to-end tests with a browser, with a somewhat slightly reduced amount of pain.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Brut uses <a href="https://playwright.dev/" target="_blank" rel="noreferrer">Playwright</a> and the <a href="https://playwright-ruby-client.vercel.app/" target="_blank" rel="noreferrer">playwright-ruby-client</a> to allow you to write end-to-end tests that use a web browser. Brut sets up headless Chromium to do this.</p><p>You can run End-to-End (e2e) tests with <code>bin/test e2e</code>. You must use this to run individual tests as well, since this will ensure proper set up for the tests, which is more than is needed for a normal unit test.</p><h3 id="using-playwright" tabindex="-1">Using Playwright <a class="header-anchor" href="#using-playwright" aria-label="Permalink to &quot;Using Playwright&quot;">​</a></h3><p>At a high level, e2e tests look like normal RSpec tests:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">require</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;spec_helper&quot;</span></span>
 <span class="line"></span>
 <span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">RSpec</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">describe</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;logging into the website&quot;</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> do</span></span>
 <span class="line"></span>
@@ -25,4 +25,4 @@ import{_ as e,c as t,o as a,ag as i}from"./chunks/framework.1L-BeKqY.js";const k
 <span class="line"><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;">  # ...</span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">end</span></span></code></pre></div><p>You can also configure behavior with environment variables:</p><table tabindex="0"><thead><tr><th>Variable</th><th>Default</th><th>Purpose</th></tr></thead><tbody><tr><td><code>E2E_TIMEOUT_MS</code></td><td>5000</td><td>Number of milliseconds Playwright will wait for a locator to appear</td></tr><tr><td><code>E2E_SLOW_MO</code></td><td>0</td><td>Number of milliseconds Playwright will pause between operations. Useful to detect race conditions</td></tr><tr><td><code>E2E_RECORD_VIDEOS</code></td><td>unset</td><td>If set, videos of each test run are saved in <code>tmp/e2e-videos</code></td></tr></tbody></table><h3 id="quirks-of-playwright" tabindex="-1">Quirks of Playwright <a class="header-anchor" href="#quirks-of-playwright" aria-label="Permalink to &quot;Quirks of Playwright&quot;">​</a></h3><p>The Playwright JavaScript API is heavily asycnhronous, requiring liberal use of <code>await</code>. The <code>playwright-ruby-client</code> wrapper abstracts that so you can write more straightfoward code.</p><p>The main thing to be aware of is that locators that fail only fail when you attempt to assert something.</p><p>For example</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">button</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> = page.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">locator</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;form button&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">) </span><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"># suppose this button doesn&#39;t exist</span></span>
 <span class="line"></span>
-<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">button.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">click</span><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"> # This is where you&#39;ll see a failure</span></span></code></pre></div><p>This hidden asynchronous behavior also means that certain calls will wait a period of time for the element you are locating to appear. This is why the example test above works without having to explicitly wait for a page refresh. After <code>button.click</code>, presumably the back-end is contacted and the page is re-rendered with an error. As long as that happens within a second or so, the code will wait for an element matching <code>[role=&#39;alert&#39;]</code> to show up.</p><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><p>E2e tests are slow. They can also be flaky if you aren&#39;t careful in how you write them and how you author your HTML.</p><h3 id="test-major-flows-not-exhaustive-branches" tabindex="-1">Test Major Flows, Not Exhaustive Branches <a class="header-anchor" href="#test-major-flows-not-exhaustive-branches" aria-label="Permalink to &quot;Test Major Flows, Not Exhaustive Branches&quot;">​</a></h3><p>E2e tests give the most value when they assert that a sequence of actions the visitor takes result in what you expect—a &quot;major flow&quot;. Testing some error cases can be useful, but you should not use e2e tests to assert every single possible thing that could happen on a page.</p><p>In fact, your app might be better off leaving some behaviors better untested instead of tested by an e2e test. Use your judgement and be aware of the carrying cost of each e2e test.</p><h3 id="use-css-selectors" tabindex="-1">Use CSS Selectors <a class="header-anchor" href="#use-css-selectors" aria-label="Permalink to &quot;Use CSS Selectors&quot;">​</a></h3><p>The main Playwright documentation encourages you to locate elements by &quot;accessible names&quot; and other indirect ways of finding elements. In practice, this is error prone and tedious. Determining the accessible name of an element is not always easy.</p><p>We recommend you assess your app&#39;s accessibility in another way than trying to do it while performing end-to-end tests. Instead, locate elements with CSS selectors—this is what you&#39;d use to debug your app so it makes sense as a testing technique.</p><p>Insulating your end-to-end tests from markup changes does not produce significant savings and can make tests more difficult to write.</p><h3 id="testing-must-inform-your-html" tabindex="-1">Testing Must Inform your HTML <a class="header-anchor" href="#testing-must-inform-your-html" aria-label="Permalink to &quot;Testing Must Inform your HTML&quot;">​</a></h3><p>To allow CSS selectors to survive minor changes to a page, your HTML should be authored with testing in mind. In the example above, we locate the flash by looking for <code>[role=&#39;alert&#39;]</code>, since this is the most semantically correct way to mark up a flash message that contains an error.</p><p>ARIA roles that should be applied for accessibility purposes can be leveraged as locators, as can custom elements. Remember that any custom element is valid, even if it has no associated JavaScript. Custom elements are an excellent way to &quot;tag&quot; markup for use in tests or progressively-enhanced behavior.</p><p>CSS classes, on the other hand, are not a good candidate for identifying markup in a test. CSS classes exist to afford visual styling of elements and are the most likely to change as the app evolves. A better fallback if there is no other way to locate an element is to use <code>data-testid</code>. It makes itself painfully clear why it&#39;s there. Use this sparingly, but it&#39;s there if you need it.</p><h3 id="asserting-the-lack-of-content-basically-doesn-t-work" tabindex="-1">Asserting the Lack of Content Basically Doesn&#39;t Work <a class="header-anchor" href="#asserting-the-lack-of-content-basically-doesn-t-work" aria-label="Permalink to &quot;Asserting the Lack of Content Basically Doesn&#39;t Work&quot;">​</a></h3><p>To assert that some content or an element <strong>is not</strong> on the page requires locating it and waiting the timeout for that locate to fail. This sucks. Don&#39;t do it.</p><p>If you need to assert that something did not happen, you may want to design your page or app such that markup appears that indicates whatever it is didn&#39;t happen. This is not ideal, but a web page is a living thing that never stops changing, so your test can&#39;t just assume it&#39;s all synchronous.</p><h3 id="try-to-use-the-defaults-for-timeouts" tabindex="-1">Try to Use the Defaults for Timeouts <a class="header-anchor" href="#try-to-use-the-defaults-for-timeouts" aria-label="Permalink to &quot;Try to Use the Defaults for Timeouts&quot;">​</a></h3><p>Your app should not take 5 seconds to do anythning, especially not inside a test. You may need to bump up the timeout to figure out what&#39;s going wrong, or set <code>E2E_SLOW_MO</code> to watch a video test, but once you&#39;ve sorted out the issue, restore these to their defaults.</p><p>If you <em>must</em> set <code>e2e_timeout</code> as metadata on test, <strong>explain why</strong> and try removing it every so often to make sure it&#39;s still needed.</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated June 13, 2025</em></p><p>The test server is run via <code>bin/test-server</code>.</p>`,50)]))}const u=e(n,[["render",o]]);export{k as __pageData,u as default};
+<span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">button.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">click</span><span style="--shiki-light:#6A737D;--shiki-dark:#6A737D;"> # This is where you&#39;ll see a failure</span></span></code></pre></div><p>This hidden asynchronous behavior also means that certain calls will wait a period of time for the element you are locating to appear. This is why the example test above works without having to explicitly wait for a page refresh. After <code>button.click</code>, presumably the back-end is contacted and the page is re-rendered with an error. As long as that happens within a second or so, the code will wait for an element matching <code>[role=&#39;alert&#39;]</code> to show up.</p><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><p>E2e tests are slow. They can also be flaky if you aren&#39;t careful in how you write them and how you author your HTML.</p><h3 id="test-major-flows-not-exhaustive-branches" tabindex="-1">Test Major Flows, Not Exhaustive Branches <a class="header-anchor" href="#test-major-flows-not-exhaustive-branches" aria-label="Permalink to &quot;Test Major Flows, Not Exhaustive Branches&quot;">​</a></h3><p>E2e tests give the most value when they assert that a sequence of actions the visitor takes result in what you expect—a &quot;major flow&quot;. Testing some error cases can be useful, but you should not use e2e tests to assert every single possible thing that could happen on a page.</p><p>In fact, your app might be better off leaving some behaviors better untested instead of tested by an e2e test. Use your judgement and be aware of the carrying cost of each e2e test.</p><h3 id="use-css-selectors" tabindex="-1">Use CSS Selectors <a class="header-anchor" href="#use-css-selectors" aria-label="Permalink to &quot;Use CSS Selectors&quot;">​</a></h3><p>The main Playwright documentation encourages you to locate elements by &quot;accessible names&quot; and other indirect ways of finding elements. In practice, this is error prone and tedious. Determining the accessible name of an element is not always easy.</p><p>We recommend you assess your app&#39;s accessibility in another way than trying to do it while performing end-to-end tests. Instead, locate elements with CSS selectors—this is what you&#39;d use to debug your app so it makes sense as a testing technique.</p><p>Insulating your end-to-end tests from markup changes does not produce significant savings and can make tests more difficult to write.</p><h3 id="testing-must-inform-your-html" tabindex="-1">Testing Must Inform your HTML <a class="header-anchor" href="#testing-must-inform-your-html" aria-label="Permalink to &quot;Testing Must Inform your HTML&quot;">​</a></h3><p>To allow CSS selectors to survive minor changes to a page, your HTML should be authored with testing in mind. In the example above, we locate the flash by looking for <code>[role=&#39;alert&#39;]</code>, since this is the most semantically correct way to mark up a flash message that contains an error.</p><p>ARIA roles that should be applied for accessibility purposes can be leveraged as locators, as can custom elements. Remember that any custom element is valid, even if it has no associated JavaScript. Custom elements are an excellent way to &quot;tag&quot; markup for use in tests or progressively-enhanced behavior.</p><p>CSS classes, on the other hand, are not a good candidate for identifying markup in a test. CSS classes exist to afford visual styling of elements and are the most likely to change as the app evolves. A better fallback if there is no other way to locate an element is to use <code>data-testid</code>. It makes itself painfully clear why it&#39;s there. Use this sparingly, but it&#39;s there if you need it.</p><h3 id="asserting-the-lack-of-content-basically-doesn-t-work" tabindex="-1">Asserting the Lack of Content Basically Doesn&#39;t Work <a class="header-anchor" href="#asserting-the-lack-of-content-basically-doesn-t-work" aria-label="Permalink to &quot;Asserting the Lack of Content Basically Doesn&#39;t Work&quot;">​</a></h3><p>To assert that some content or an element <strong>is not</strong> on the page requires locating it and waiting the timeout for that locate to fail. This sucks. Don&#39;t do it.</p><p>If you need to assert that something did not happen, you may want to design your page or app such that markup appears that indicates whatever it is didn&#39;t happen. This is not ideal, but a web page is a living thing that never stops changing, so your test can&#39;t just assume it&#39;s all synchronous.</p><h3 id="try-to-use-the-defaults-for-timeouts" tabindex="-1">Try to Use the Defaults for Timeouts <a class="header-anchor" href="#try-to-use-the-defaults-for-timeouts" aria-label="Permalink to &quot;Try to Use the Defaults for Timeouts&quot;">​</a></h3><p>Your app should not take 5 seconds to do anythning, especially not inside a test. You may need to bump up the timeout to figure out what&#39;s going wrong, or set <code>E2E_SLOW_MO</code> to watch a video test, but once you&#39;ve sorted out the issue, restore these to their defaults.</p><p>If you <em>must</em> set <code>e2e_timeout</code> as metadata on test, <strong>explain why</strong> and try removing it every so often to make sure it&#39;s still needed.</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated June 13, 2025</em></p><p>The test server is run via <code>bin/test-server</code>.</p>`,50)])])}const u=e(n,[["render",o]]);export{k as __pageData,u as default};

data/docs/assets/end-to-end-tests.md.BJJdNDYL.lean.js

@@ -0,0 +1 @@
+import{_ as e,c as t,o as a,ag as i}from"./chunks/framework.C4nOkCZI.js";const k=JSON.parse('{"title":"End to End Tests","description":"","frontmatter":{},"headers":[],"relativePath":"end-to-end-tests.md","filePath":"end-to-end-tests.md"}'),n={name:"end-to-end-tests.md"};function o(l,s,h,r,p,d){return a(),t("div",null,[...s[0]||(s[0]=[i("",50)])])}const u=e(n,[["render",o]]);export{k as __pageData,u as default};

data/docs/assets/{features.md.DPFXsy0z.js → features.md.BDWxnyNO.js}

@@ -1,4 +1,4 @@
-import{_ as i,c as a,o as n,ag as t}from"./chunks/framework.1L-BeKqY.js";const E=JSON.parse(`{"title":"Quick Tour of Brut's Features","description":"","frontmatter":{},"headers":[],"relativePath":"features.md","filePath":"features.md"}`),e={name:"features.md"};function l(h,s,p,k,r,d){return n(),a("div",null,s[0]||(s[0]=[t(`<h1 id="quick-tour-of-brut-s-features" tabindex="-1">Quick Tour of Brut&#39;s Features <a class="header-anchor" href="#quick-tour-of-brut-s-features" aria-label="Permalink to &quot;Quick Tour of Brut&#39;s Features&quot;">​</a></h1><h2 id="pages" tabindex="-1">Pages <a class="header-anchor" href="#pages" aria-label="Permalink to &quot;Pages&quot;">​</a></h2><p>A <a href="/pages.html"><em>Page</em></a> models, well, a web page. It&#39;s a class that holds all the data necessary to generate its HTML as well as a method called <code>page_template</code>, which generates the HTML via Phlex.</p><p>A page&#39;s routing is convention-based and starts with a URL:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">class</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> App</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> &lt;</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> Brut</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">Framework</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">App</span></span>
+import{_ as i,c as a,o as n,ag as t}from"./chunks/framework.C4nOkCZI.js";const E=JSON.parse(`{"title":"Quick Tour of Brut's Features","description":"","frontmatter":{},"headers":[],"relativePath":"features.md","filePath":"features.md"}`),e={name:"features.md"};function l(h,s,p,k,r,d){return n(),a("div",null,[...s[0]||(s[0]=[t(`<h1 id="quick-tour-of-brut-s-features" tabindex="-1">Quick Tour of Brut&#39;s Features <a class="header-anchor" href="#quick-tour-of-brut-s-features" aria-label="Permalink to &quot;Quick Tour of Brut&#39;s Features&quot;">​</a></h1><h2 id="pages" tabindex="-1">Pages <a class="header-anchor" href="#pages" aria-label="Permalink to &quot;Pages&quot;">​</a></h2><p>A <a href="/pages.html"><em>Page</em></a> models, well, a web page. It&#39;s a class that holds all the data necessary to generate its HTML as well as a method called <code>page_template</code>, which generates the HTML via Phlex.</p><p>A page&#39;s routing is convention-based and starts with a URL:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">class</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> App</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> &lt;</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> Brut</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">Framework</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">App</span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">  def</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> id</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">           =</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;my-app&quot;</span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">  def</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> organization</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> =</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;my-org&quot;</span></span>
 <span class="line"></span>
@@ -151,4 +151,4 @@ import{_ as i,c as a,o as n,ag as t}from"./chunks/framework.1L-BeKqY.js";const E
 <span class="line"></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">class</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> DB</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">::</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">Household</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> &lt;</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> AppDataModel</span></span>
 <span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">  one_to_many </span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">:accounts</span></span>
-<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">end</span></span></code></pre></div><h2 id="domain-and-business-logic" tabindex="-1">Domain and Business Logic <a class="header-anchor" href="#domain-and-business-logic" aria-label="Permalink to &quot;Domain and Business Logic&quot;">​</a></h2><p>Brut uses Zeitwerk for code loading, so any directories you create will be auto-loaded and refreshed during development. This means that you can create a class named <code>Household</code> in <code>app/src/back_end/domain/household.rb</code> and it would be loaded. Or, you could create <code>HouseholdService</code> in <code>app/src/back_end/services/household_service.rb</code> if you like.</p><div class="tip custom-block github-alert"><p class="custom-block-title">TIP</p><p>Providing a generally-useful abstraction for business or domain logic is not usually feasible. Thus, Brut doesn&#39;t provide much beyond Zeitwerk&#39;s auto-loading feature. It may provide more assistance in the future, but for now, Brut&#39;s approach is to free you from any prescription or moral imperative. Manage your domain and business logic how you see fit. You know your domain and team better than we do.</p></div><h2 id="testing" tabindex="-1">Testing <a class="header-anchor" href="#testing" aria-label="Permalink to &quot;Testing&quot;">​</a></h2><p>Brut provides support for three types of tests:</p><ul><li>Unit Tests, using RSpec</li><li>End-to-end tests, using RSpec and Playwright</li><li>Custom Element tests, written in JavaScript, using Mocha</li></ul><p>Since Brut is based on classes, objects, and methods, your unit tests will usually be straightforward, however Brut provides helpers to test your Page and Component HTML using Nokogiri. FactoryBot is included and configured to manage test data.</p><h2 id="tasks" tabindex="-1">Tasks <a class="header-anchor" href="#tasks" aria-label="Permalink to &quot;Tasks&quot;">​</a></h2><p>Brut doesn&#39;t use Rake tasks. It uses CLI apps powered by Ruby&#39;s <code>OptionParser</code>. Brut provides bootstrapping classes to make your own CLIs, as well as some light abstractions to make <code>OptionParser</code> a little more ergonomic. Brut&#39;s dev and production management CLIs are built using this support.</p><h2 id="observability" tabindex="-1">Observability <a class="header-anchor" href="#observability" aria-label="Permalink to &quot;Observability&quot;">​</a></h2><p>Brut has built-in support for <a href="https://opentelemetry.io/" target="_blank" rel="noreferrer">OpenTelemetry</a>. Brut includes configuration for the <a href="https://github.com/CtrlSpice/otel-desktop-viewer" target="_blank" rel="noreferrer">otel-desktop-viewer</a> or a text-based viewer suitable for development. For production, most observability vendors provide OpenTelemetry ingestion any many have free tiers.</p><p>Brut does support logging, however you are encouraged to use OpenTelemetry instead.</p>`,71)]))}const g=i(e,[["render",l]]);export{E as __pageData,g as default};
+<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">end</span></span></code></pre></div><h2 id="domain-and-business-logic" tabindex="-1">Domain and Business Logic <a class="header-anchor" href="#domain-and-business-logic" aria-label="Permalink to &quot;Domain and Business Logic&quot;">​</a></h2><p>Brut uses Zeitwerk for code loading, so any directories you create will be auto-loaded and refreshed during development. This means that you can create a class named <code>Household</code> in <code>app/src/back_end/domain/household.rb</code> and it would be loaded. Or, you could create <code>HouseholdService</code> in <code>app/src/back_end/services/household_service.rb</code> if you like.</p><div class="tip custom-block github-alert"><p class="custom-block-title">TIP</p><p>Providing a generally-useful abstraction for business or domain logic is not usually feasible. Thus, Brut doesn&#39;t provide much beyond Zeitwerk&#39;s auto-loading feature. It may provide more assistance in the future, but for now, Brut&#39;s approach is to free you from any prescription or moral imperative. Manage your domain and business logic how you see fit. You know your domain and team better than we do.</p></div><h2 id="testing" tabindex="-1">Testing <a class="header-anchor" href="#testing" aria-label="Permalink to &quot;Testing&quot;">​</a></h2><p>Brut provides support for three types of tests:</p><ul><li>Unit Tests, using RSpec</li><li>End-to-end tests, using RSpec and Playwright</li><li>Custom Element tests, written in JavaScript, using Mocha</li></ul><p>Since Brut is based on classes, objects, and methods, your unit tests will usually be straightforward, however Brut provides helpers to test your Page and Component HTML using Nokogiri. FactoryBot is included and configured to manage test data.</p><h2 id="tasks" tabindex="-1">Tasks <a class="header-anchor" href="#tasks" aria-label="Permalink to &quot;Tasks&quot;">​</a></h2><p>Brut doesn&#39;t use Rake tasks. It uses CLI apps powered by Ruby&#39;s <code>OptionParser</code>. Brut provides bootstrapping classes to make your own CLIs, as well as some light abstractions to make <code>OptionParser</code> a little more ergonomic. Brut&#39;s dev and production management CLIs are built using this support.</p><h2 id="observability" tabindex="-1">Observability <a class="header-anchor" href="#observability" aria-label="Permalink to &quot;Observability&quot;">​</a></h2><p>Brut has built-in support for <a href="https://opentelemetry.io/" target="_blank" rel="noreferrer">OpenTelemetry</a>. Brut includes configuration for the <a href="https://github.com/CtrlSpice/otel-desktop-viewer" target="_blank" rel="noreferrer">otel-desktop-viewer</a> or a text-based viewer suitable for development. For production, most observability vendors provide OpenTelemetry ingestion any many have free tiers.</p><p>Brut does support logging, however you are encouraged to use OpenTelemetry instead.</p>`,71)])])}const g=i(e,[["render",l]]);export{E as __pageData,g as default};

data/docs/assets/features.md.BDWxnyNO.lean.js

@@ -0,0 +1 @@
+import{_ as i,c as a,o as n,ag as t}from"./chunks/framework.C4nOkCZI.js";const E=JSON.parse(`{"title":"Quick Tour of Brut's Features","description":"","frontmatter":{},"headers":[],"relativePath":"features.md","filePath":"features.md"}`),e={name:"features.md"};function l(h,s,p,k,r,d){return n(),a("div",null,[...s[0]||(s[0]=[t("",71)])])}const g=i(e,[["render",l]]);export{E as __pageData,g as default};

data/docs/assets/{flash-and-session.md.nPvUpnUx.js → flash-and-session.md.CUsMxoNl.js}

@@ -1,4 +1,4 @@
-import{_ as i,c as a,o as n,ag as e}from"./chunks/framework.1L-BeKqY.js";const g=JSON.parse('{"title":"Flash and Session","description":"","frontmatter":{},"headers":[],"relativePath":"flash-and-session.md","filePath":"flash-and-session.md"}'),t={name:"flash-and-session.md"};function h(l,s,p,k,r,d){return n(),a("div",null,s[0]||(s[0]=[e(`<h1 id="flash-and-session" tabindex="-1">Flash and Session <a class="header-anchor" href="#flash-and-session" aria-label="Permalink to &quot;Flash and Session&quot;">​</a></h1><p>Brut sessions are stored in cookies, encrypted to prevent tampering. The <em>flash</em>, which is a way to temporarily store small bits of information between page loads, is encoded in the session.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Unlike Rails, the session and flash are presented to you as objects, not Hashes of Whatever. By declaring the <code>session:</code> parameter on an initializer, you&#39;ll be given the current session for the request as an <code>AppSession</code>, which inherits from <a href="/api/Brut/FrontEnd/Session.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::Session</code></a>. Similarly, declaring <code>flash:</code>, you&#39;ll get a <a href="/api/Brut/FrontEnd/Flash.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::Flash</code></a>.</p><p>The idea is to use Ruby&#39;s type system to describe what data is in the session and flash.</p><h3 id="session" tabindex="-1">Session <a class="header-anchor" href="#session" aria-label="Permalink to &quot;Session&quot;">​</a></h3><p>Brut&#39;s session is somewhat richer than you might get from other frameworks. In particular, the session can provide you:</p><ul><li>The current <a href="/api/Brut/I18n/HTTPAcceptLanguage.html" target="_self" rel="noopener" data-no-router><code>Brut::I18n::HTTPAcceptLanguage</code></a>, which is the visitor&#39;s locale. See <a href="/i18n.html">I18n</a> for how this works and how to use this value.</li><li>The timezone as provided by the browser.</li><li>An explicitly-set timezone that may or may not be what the browser provided. See <a href="/space-time-continuum.html">Space-Time Continuum</a> for more details.</li></ul><p>To access the session, declare it as a keyword argument to your page, handler, or global component&#39;s intitializer:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">class</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> HomePage</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> &lt;</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> AppPage</span></span>
+import{_ as i,c as a,o as n,ag as e}from"./chunks/framework.C4nOkCZI.js";const g=JSON.parse('{"title":"Flash and Session","description":"","frontmatter":{},"headers":[],"relativePath":"flash-and-session.md","filePath":"flash-and-session.md"}'),t={name:"flash-and-session.md"};function h(l,s,p,k,r,d){return n(),a("div",null,[...s[0]||(s[0]=[e(`<h1 id="flash-and-session" tabindex="-1">Flash and Session <a class="header-anchor" href="#flash-and-session" aria-label="Permalink to &quot;Flash and Session&quot;">​</a></h1><p>Brut sessions are stored in cookies, encrypted to prevent tampering. The <em>flash</em>, which is a way to temporarily store small bits of information between page loads, is encoded in the session.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>Unlike Rails, the session and flash are presented to you as objects, not Hashes of Whatever. By declaring the <code>session:</code> parameter on an initializer, you&#39;ll be given the current session for the request as an <code>AppSession</code>, which inherits from <a href="/api/Brut/FrontEnd/Session.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::Session</code></a>. Similarly, declaring <code>flash:</code>, you&#39;ll get a <a href="/api/Brut/FrontEnd/Flash.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::Flash</code></a>.</p><p>The idea is to use Ruby&#39;s type system to describe what data is in the session and flash.</p><h3 id="session" tabindex="-1">Session <a class="header-anchor" href="#session" aria-label="Permalink to &quot;Session&quot;">​</a></h3><p>Brut&#39;s session is somewhat richer than you might get from other frameworks. In particular, the session can provide you:</p><ul><li>The current <a href="/api/Brut/I18n/HTTPAcceptLanguage.html" target="_self" rel="noopener" data-no-router><code>Brut::I18n::HTTPAcceptLanguage</code></a>, which is the visitor&#39;s locale. See <a href="/i18n.html">I18n</a> for how this works and how to use this value.</li><li>The timezone as provided by the browser.</li><li>An explicitly-set timezone that may or may not be what the browser provided. See <a href="/space-time-continuum.html">Space-Time Continuum</a> for more details.</li></ul><p>To access the session, declare it as a keyword argument to your page, handler, or global component&#39;s intitializer:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">class</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> HomePage</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> &lt;</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> AppPage</span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">  def</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> initialize</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">session:</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">)</span></span>
 <span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">    @session </span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">=</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> session</span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">  end</span></span>
@@ -76,4 +76,4 @@ import{_ as i,c as a,o as n,ag as e}from"./chunks/framework.1L-BeKqY.js";const g
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">      end</span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">    end</span></span>
 <span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">  end</span></span>
-<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">end</span></span></code></pre></div><p>See <a href="/recipes/custom-flash.html">using your own Flash class</a> to see how to enhance Brut&#39;s flash with your own logic.</p><h2 id="testing" tabindex="-1">Testing <a class="header-anchor" href="#testing" aria-label="Permalink to &quot;Testing&quot;">​</a></h2><p>Testing your session or flash classes may not be super valuable, however they are normal Ruby objects so you can test them in a conventional way. Although you are discouraged from using <code>[]</code> and <code>[]=</code> as the public API of your session or flash, they can be useful for assertions or test setup.</p><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><p>Do not treat the session or flash as a Hash of Whatever. Isolate all magic keys to the class and provide a rich API. It doesn&#39;t take that much effort and will make your app way easier to manage.</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated May 7, 2025</em></p><p>The session is based on <a href="https://github.com/rack/rack-session" target="_blank" rel="noreferrer"><code>Rack::Session</code></a>, which is configured explicitly in your app&#39;s <code>config.ru</code>. (TBD: WHY?)</p><p>The session object itself is created on demand for any route hook that needs it. Since <a href="/api/Brut/FrontEnd/RouteHooks/SetupRequestContext.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::RouteHooks::SetupRequestContext</code></a> requires the session, the <a href="/api/Brut/FrontEnd/RequestContext.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::RequestContext</code></a> is created here and given the session (and flash) that is used for subsequent hooks and HTML generation.</p><p>The flash is created largely on-demand and is a special hash serialized into the session. The hash contains the current age of the flash and then all the messages. This format could use improvement and may change. <a href="/api/Brut/FrontEnd/RouteHooks/AgeFlash.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::RouteHooks::AgeFlash</code></a> is a route hook that handles increasing the age of the flash, however the flash itself controls when to &quot;age out&quot; messages. None of this is currently configurable.</p>`,40)]))}const c=i(t,[["render",h]]);export{g as __pageData,c as default};
+<span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">end</span></span></code></pre></div><p>See <a href="/recipes/custom-flash.html">using your own Flash class</a> to see how to enhance Brut&#39;s flash with your own logic.</p><h2 id="testing" tabindex="-1">Testing <a class="header-anchor" href="#testing" aria-label="Permalink to &quot;Testing&quot;">​</a></h2><p>Testing your session or flash classes may not be super valuable, however they are normal Ruby objects so you can test them in a conventional way. Although you are discouraged from using <code>[]</code> and <code>[]=</code> as the public API of your session or flash, they can be useful for assertions or test setup.</p><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><p>Do not treat the session or flash as a Hash of Whatever. Isolate all magic keys to the class and provide a rich API. It doesn&#39;t take that much effort and will make your app way easier to manage.</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated May 7, 2025</em></p><p>The session is based on <a href="https://github.com/rack/rack-session" target="_blank" rel="noreferrer"><code>Rack::Session</code></a>, which is configured explicitly in your app&#39;s <code>config.ru</code>. (TBD: WHY?)</p><p>The session object itself is created on demand for any route hook that needs it. Since <a href="/api/Brut/FrontEnd/RouteHooks/SetupRequestContext.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::RouteHooks::SetupRequestContext</code></a> requires the session, the <a href="/api/Brut/FrontEnd/RequestContext.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::RequestContext</code></a> is created here and given the session (and flash) that is used for subsequent hooks and HTML generation.</p><p>The flash is created largely on-demand and is a special hash serialized into the session. The hash contains the current age of the flash and then all the messages. This format could use improvement and may change. <a href="/api/Brut/FrontEnd/RouteHooks/AgeFlash.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::RouteHooks::AgeFlash</code></a> is a route hook that handles increasing the age of the flash, however the flash itself controls when to &quot;age out&quot; messages. None of this is currently configurable.</p>`,40)])])}const c=i(t,[["render",h]]);export{g as __pageData,c as default};

data/docs/assets/flash-and-session.md.CUsMxoNl.lean.js

@@ -0,0 +1 @@
+import{_ as i,c as a,o as n,ag as e}from"./chunks/framework.C4nOkCZI.js";const g=JSON.parse('{"title":"Flash and Session","description":"","frontmatter":{},"headers":[],"relativePath":"flash-and-session.md","filePath":"flash-and-session.md"}'),t={name:"flash-and-session.md"};function h(l,s,p,k,r,d){return n(),a("div",null,[...s[0]||(s[0]=[e("",40)])])}const c=i(t,[["render",h]]);export{g as __pageData,c as default};

data/docs/assets/{form-constraints.md.KTv5cdR4.js → form-constraints.md.KlfXSKm2.js}

@@ -1,4 +1,4 @@
-import{_ as i,c as a,o as t,ag as n}from"./chunks/framework.1L-BeKqY.js";const E=JSON.parse('{"title":"Form Constraint Validations","description":"","frontmatter":{},"headers":[],"relativePath":"form-constraints.md","filePath":"form-constraints.md"}'),e={name:"form-constraints.md"};function h(l,s,p,k,r,o){return t(),a("div",null,s[0]||(s[0]=[n(`<h1 id="form-constraint-validations" tabindex="-1">Form Constraint Validations <a class="header-anchor" href="#form-constraint-validations" aria-label="Permalink to &quot;Form Constraint Validations&quot;">​</a></h1><p>Aside from simply collecting data and submitting it to the server, form data has <em>constraints</em> that must be validated before data is accepted. Brut provides support for both client-side and server-side constraints.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>When validating form data against its constraints, Brut provides assistance in two ways:</p><ul><li>Specifying constraint violations that only the server can evaluate.</li><li>Unifying the user experience for both client-side and server-side constraint violations.</li></ul><h3 id="specifying-constraints" tabindex="-1">Specifying Constraints <a class="header-anchor" href="#specifying-constraints" aria-label="Permalink to &quot;Specifying Constraints&quot;">​</a></h3><p>For both client and server-side constraint violations, Brut uses the <a href="/api/Brut/FrontEnd/Forms/ConstraintViolation.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::Forms::ConstraintViolation</code></a> class to represent a specific error on a specific field. This class is a wrapper around an i18n key, context to generate that key&#39;s messaging, and a flag indicating if the violation is server or client side.</p><p>To specify a server-side constraint violation on a form, call <code>server_side_constraint_violation</code>:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">form.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">server_side_constraint_violation</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span></span>
+import{_ as i,c as a,o as t,ag as n}from"./chunks/framework.C4nOkCZI.js";const E=JSON.parse('{"title":"Form Constraint Validations","description":"","frontmatter":{},"headers":[],"relativePath":"form-constraints.md","filePath":"form-constraints.md"}'),e={name:"form-constraints.md"};function h(l,s,p,k,r,o){return t(),a("div",null,[...s[0]||(s[0]=[n(`<h1 id="form-constraint-validations" tabindex="-1">Form Constraint Validations <a class="header-anchor" href="#form-constraint-validations" aria-label="Permalink to &quot;Form Constraint Validations&quot;">​</a></h1><p>Aside from simply collecting data and submitting it to the server, form data has <em>constraints</em> that must be validated before data is accepted. Brut provides support for both client-side and server-side constraints.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to &quot;Overview&quot;">​</a></h2><p>When validating form data against its constraints, Brut provides assistance in two ways:</p><ul><li>Specifying constraint violations that only the server can evaluate.</li><li>Unifying the user experience for both client-side and server-side constraint violations.</li></ul><h3 id="specifying-constraints" tabindex="-1">Specifying Constraints <a class="header-anchor" href="#specifying-constraints" aria-label="Permalink to &quot;Specifying Constraints&quot;">​</a></h3><p>For both client and server-side constraint violations, Brut uses the <a href="/api/Brut/FrontEnd/Forms/ConstraintViolation.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::Forms::ConstraintViolation</code></a> class to represent a specific error on a specific field. This class is a wrapper around an i18n key, context to generate that key&#39;s messaging, and a flag indicating if the violation is server or client side.</p><p>To specify a server-side constraint violation on a form, call <code>server_side_constraint_violation</code>:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">form.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">server_side_constraint_violation</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span></span>
 <span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">  input_name:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> :name</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">,</span></span>
 <span class="line"><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">  key:</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> :name_is_taken</span></span>
 <span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">)</span></span></code></pre></div><p>The <code>input_name</code> is the same value you used when creating your form class, and <code>key</code> is an <a href="/i18n.html">I18n</a> key that will have <code>cv.ss</code> prepended to it (for **c*onstratin <strong>v</strong>iolation, <strong>s</strong>server <strong>s</strong>ide). Thus, the key in the above example is <code>&quot;cv.ss.name_is_taken&quot;</code>.</p><p>Brut forms will automatically add client-side constraints based on the value assigned to the input. For example, since <code>name</code> must be 3 or more characters, this code would implicitly set <code>:rangeOverflow</code> as a client-side constraint violation:</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">form.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">input</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;">:name</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">).</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">value</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> =</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;"> &quot;xx&quot;</span></span></code></pre></div><h3 id="accessing-constraints-when-generating-html" tabindex="-1">Accessing Constraints when Generating HTML <a class="header-anchor" href="#accessing-constraints-when-generating-html" aria-label="Permalink to &quot;Accessing Constraints when Generating HTML&quot;">​</a></h3><p><a href="/api/Brut/FrontEnd/Form.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::Form</code></a> provides the method <code>constraint_violations</code> to access the constraints, however we recommend using the <a href="/api/Brut/FrontEnd/Components/ConstraintViolations.html" target="_self" rel="noopener" data-no-router><code>Brut::FrontEnd::Components::ConstraintViolations</code></a> component instead. This component generates particular markup useful for unifying the UX around constraint violations, which we&#39;ll discuss in a moment.</p><div class="language-ruby vp-adaptive-theme"><button title="Copy Code" class="copy"></button><span class="lang">ruby</span><pre class="shiki shiki-themes github-light github-dark vp-code" tabindex="0"><code><span class="line"><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;">class</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> NewWidgetPage</span><span style="--shiki-light:#D73A49;--shiki-dark:#F97583;"> &lt;</span><span style="--shiki-light:#005CC5;--shiki-dark:#79B8FF;"> AppPage</span></span>
@@ -87,4 +87,4 @@ import{_ as i,c as a,o as t,ag as n}from"./chunks/framework.1L-BeKqY.js";const E
 <span class="line"><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">button.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">click</span></span>
 <span class="line"></span>
 <span class="line"><span style="--shiki-light:#E36209;--shiki-dark:#FFAB70;">brut_cv</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> = page.</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">locator</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;brut-cv-messages[input-name=&#39;name&#39;] brut-cv&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">)</span></span>
-<span class="line"><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">expect</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(brut_cv).</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">to</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> have_text</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;too short&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">)</span></span></code></pre></div><p>Playwright will wait for the <code>brut-cv</code> containing the text &quot;too short&quot; to appear on the page, so you should not have any race conditions.</p><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><h3 id="utility-css-is-tricky-here" tabindex="-1">Utility CSS is Tricky Here <a class="header-anchor" href="#utility-css-is-tricky-here" aria-label="Permalink to &quot;Utility CSS is Tricky Here&quot;">​</a></h3><p>Utility CSS like BrutCSS or TailwindCSS isn&#39;t well-suited to targeting elements based on custom elements or attributes. You will need to write CSS or need to create your own utility CSS for these situations.</p><p>In our opinion, writing CSS for something like this isn&#39;t a big deal as it can reduce duplcation via the use of custom properties from your CSS library/design system and it tends to be stable once created.</p><h3 id="learn-to-be-ok-with-the-browser-s-ux" tabindex="-1">Learn to Be OK with the Browser&#39;s UX <a class="header-anchor" href="#learn-to-be-ok-with-the-browser-s-ux" aria-label="Permalink to &quot;Learn to Be OK with the Browser&#39;s UX&quot;">​</a></h3><p>One complain about client-side constraint violations is that the browser often provides UX that you cannot control. This isn&#39;t ideal, but it does have the virtue of being accessible and obvious. Visitors also really don&#39;t care about how ugly it is as much as you might think. The utility and accessibility offset is as worthwhile tradeoff.</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated July 6, 2025</em></p><p>Nothing at this time.</p>`,54)]))}const g=i(e,[["render",h]]);export{E as __pageData,g as default};
+<span class="line"><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">expect</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(brut_cv).</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;">to</span><span style="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> have_text</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span><span style="--shiki-light:#032F62;--shiki-dark:#9ECBFF;">&quot;too short&quot;</span><span style="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">)</span></span></code></pre></div><p>Playwright will wait for the <code>brut-cv</code> containing the text &quot;too short&quot; to appear on the page, so you should not have any race conditions.</p><h2 id="recommended-practices" tabindex="-1">Recommended Practices <a class="header-anchor" href="#recommended-practices" aria-label="Permalink to &quot;Recommended Practices&quot;">​</a></h2><h3 id="utility-css-is-tricky-here" tabindex="-1">Utility CSS is Tricky Here <a class="header-anchor" href="#utility-css-is-tricky-here" aria-label="Permalink to &quot;Utility CSS is Tricky Here&quot;">​</a></h3><p>Utility CSS like BrutCSS or TailwindCSS isn&#39;t well-suited to targeting elements based on custom elements or attributes. You will need to write CSS or need to create your own utility CSS for these situations.</p><p>In our opinion, writing CSS for something like this isn&#39;t a big deal as it can reduce duplcation via the use of custom properties from your CSS library/design system and it tends to be stable once created.</p><h3 id="learn-to-be-ok-with-the-browser-s-ux" tabindex="-1">Learn to Be OK with the Browser&#39;s UX <a class="header-anchor" href="#learn-to-be-ok-with-the-browser-s-ux" aria-label="Permalink to &quot;Learn to Be OK with the Browser&#39;s UX&quot;">​</a></h3><p>One complain about client-side constraint violations is that the browser often provides UX that you cannot control. This isn&#39;t ideal, but it does have the virtue of being accessible and obvious. Visitors also really don&#39;t care about how ugly it is as much as you might think. The utility and accessibility offset is as worthwhile tradeoff.</p><h2 id="technical-notes" tabindex="-1">Technical Notes <a class="header-anchor" href="#technical-notes" aria-label="Permalink to &quot;Technical Notes&quot;">​</a></h2><div class="important custom-block github-alert"><p class="custom-block-title">IMPORTANT</p><p>Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut&#39;s internals, the source code is always more correct.</p></div><p><em>Last Updated July 6, 2025</em></p><p>Nothing at this time.</p>`,54)])])}const g=i(e,[["render",h]]);export{E as __pageData,g as default};