brut 0.16.0 → 0.18.0

data/brutrb.com/recipes/text-field-component.md

@@ -1,182 +0,0 @@
-# Creating your Own Text Field Component
-
-Brut's `Brut::FrontEnd::Components::Input::InputTag` creates only the `<input>` HTML
-element.  You will likely want something more sophsticated. You can achieve this by
-creating your own component.
-
-## Feature
-
-We'll make a text field that has a label, error messages, and styling.  It will
-support three sizes: small, normal, and large.
-
-It will require a form and an input name, and optional index as well.
-
-## Recipe
-
-### Create the Initializer
-
-First, we'll create the component:
-
-```
-bin/scaffold component text_field
-```
-
-Now, edit the initializer to accept the parameters we need:
-
-```ruby
-# app/src/front_end/components/text_field_component.rb
-class TextFieldComponent < AppComponent
-  def initialize(form:,
-                 input_name:,
-                 index: 0, # default for non-array values
-                 size: :normal)
-    @form       = form
-    @input_name = input_name
-    @index      = index
-    @size       = size
-  end
-end
-```
-
-### Outline the HTML
-
-We'll want HTML like so:
-
-```html
-<label>
-  <input ...>
-  <span>LABEL HERE</span>
-  <brut-cv-messages></brut-cv-messages>
-</label>
-```
-
-Before we worry about CSS or styling, let's sketch this out in `view_template`.  The
-actual label text will come from our I18n setup. We'll assume a "labels" top-level
-section that has sections for each form and then inside that, each input name:
-
-```ruby
-# app/config/i18n/en/2_app.rb
-{
-  "labels": {
-    "LoginForm": {
-      "email": "Email addressed you used when singing up",
-      "password": "Your password",
-    }
-  }
-}
-```
-
-```ruby
-# app/src/front_end/components/text_field_component.rb
-class TextFieldComponent < AppComponent
-
-  include Brut::FrontEnd::Components
-
-  private attr_reader :form, :input_name, :index
-  def view_template
-    label do
-      InputTag(form:, input_name:, index: )
-      span { raw(t([ "labels", form.class.name, input_name ])) }
-      ConstraintViolations(form:, input_name:, index:)
-    end
-  end
-end
-```
-
-### Styling the Component
-
-Styling can happen in a few ways.  For simplicity, we'll use CSS and have minimal
-classes on our HTML.  Since the structure is all inside a `<label>`, we'll add a
-class on that, named for our component. We'll also include form and input names
-in the class to allow overriding if needed.  Lastly, we'll include the
-size as well.
-
-```ruby {8-14}
-# app/src/front_end/components/text_field_component.rb
-class TextFieldComponent < AppComponent
-
-  include Brut::FrontEnd::Components
-
-  private attr_reader :form, :input_name, :index
-  def view_template
-    label_classes = [
-      class.name,
-      class.name + "-#{@size}",
-      form.class.name,
-      input_name
-    ]
-    label(class: label_classes) do
-      InputTag(form:, input_name:, index: )
-      span { raw(t([ "labels", form.class.name, input_name ])) }
-      ConstraintViolations(form:, input_name:, index:)
-    end
-  end
-end
-```
-
-Let's create `app/src/front_end/css/TextFieldComponent.css`, which we'll need to
-`@import`:
-
-```css
-/* app/src/front_end/css/index.css */
-@import "TextFieldComponent.css";
-```
-
-The CSS will assume BrutCSS's design system is available:
-
-```css
-/* app/src/front_end/css/TextFieldComponent.css */
-.TextFieldComponent {
-  label {
-    display: flex;
-    flex-direction: column;
-    gap: var(--sp-2);
-  }
-  input {
-    border: solid thin var(--gray-500);
-    border-radius: var(--br-3);
-    padding: var(--sp-2);
-    font-size: var(--fs-3);
-  }
-  span {
-    font-size: var(--fs-2);
-    font-stye: italic;
-    color: var(--gray-400);
-  }
-  /** We assume the general styling for brut-form
-      and brut-cv exists in index.css */
-  brut-cv {
-    color: red;
-  }
-  &.TextFieldComponent-small {
-    input {
-      font-size: var(--fs-1);
-    }
-  }
-  &.TextFieldComponent-large {
-    input {
-      font-size: var(--fs-4);
-    }
-  }
-}
-```
-
-### Using the Component
-
-To use this component, we can create an instance and send it to Phlex's `render`:
-
-
-```ruby
-def view_template
-  brut_form do
-    FormTag(for: @form) do
-      render TextFieldComponent.new(form: @form,
-                                    input_name: :name)
-      render TextFieldComponent.new(form: @form,
-                                    input_name: :quantity,
-                                    size: :small)
-      button { "Save" }
-    end
-  end
-end
-```

data/brutrb.com/roadmap.md

@@ -1,52 +0,0 @@
-# Roadmap to 1.0
-
-A lot of Brut is solid, but there's several things missing from what I would
-call a 1.0 release.  Here are some ideas of what I think is needed:
-
-## Better Dev Experience
-
-* The CLI apps are all shimmed in a wierd way, expecially `mkbrut`. They should be part of the gem.
-* The output of `bin/dev` isn't great.
-* otel-desktop-viewer is cool, but not the easiest to figure out issues as compred to good 'ole logging.
-* Error pages in the app are *really* bad.
-
-## More Tests
-
-* Unit tests for all/most classes are needed. There's only a few now.
-* Integration test of `mkbrut`, all automated.
-* Web component/custom element tests need to be re-thought.
-* Test output is a wall of text stack trace and this sucks.
-* Improvements in access to Playwright features.
-* Playright is the worst E2E testing tool except all the rest. Would love a better option here.
-
-## More Complete Web Features
-
-* Content security policy is all or nothing. You can bring stuff in via CDN without disabling the feature entirely.  I want everyone using CSP, but it needs to be more configurable.
-* Websockets, server-push, etc. should be possible or at least have a recipe.
-* Learn more about importmaps.
-
-## Client-Side Improvements
-
-BrutJS is woefully incomplete.  I'd like developers to be able to accomplishe
-certain tasks without needing a framework:
-
-* Hooks into asset building to e.g. enable TailwindCSS or other tools.
-* Better use of `fetch` in more situations
-* Server-generated HTML replacement
-* Better support for "API" style back-end when a framework *is* going to be used.
-
-## Deployment
-
-Out of the box support for more deployment mechanism, at least:
-
-* Normal Heroku/`Procfile`-based deploy
-* Digital Ocean-style hosting
-* VPS?
-
-## Documentation
-
-* More recipes for how to do things
-* More complete API docs with examples
-* A unified look and feel across the board
-* Get rid of VitePress for something less client-heavy, but still great
-* Dash-accessible API docs

data/brutrb.com/routes.md

@@ -1,189 +0,0 @@
-# Routes
-
-The primary function of a web framework like Brut is to map URLs requested by the browser or an HTTP client and invoke code based on them.
-
-Brut has a fairly simple routing system that's not designed for flexibility.
-
-## Overview
-
-Your app has a subclass of `Brut::Framework::App`, called `App`. It includes a call
-to the `routes` class method.  In there, you declare your routes by using one of
-four methods:
-
-| Method                           | HTTP Method | Purpose                                                                                       |
-|----------------------------------|-------------|-----------------------------------------------------------------------------------------------|
-| `page «route»`                   | GET         | Declare a page                                                                                |
-| `form «route»`                   | POST        | Declare a form to be submitted to a handler                                                   |
-| `action «route»`                 | POST        | Declare an element-less form to be submitted to a handler (akin to Rails' `button_to` helper) |
-| `path «route», method: «method»` | `«method»`  | Declare an arbitrary path to a handler                                                        |
-
-The value for `«route»`, along with the method called, is used to determine what
-class(es) will be used to handle the route.
-
-### «route» Syntax
-
-A route is a string that contains the *path part* of a [URL](https://developer.mozilla.org/en-US/docs/Web/API/URL).  *Segments* of the path (i.e. the stuff between each forward slash `/`) can be either *static* or a *placeholder*.
-
-As such:
-
-* Only the [pathname](https://developer.mozilla.org/en-US/docs/Web/API/URL/pathname) of a request may be specified.
-* All routes must start with a slash
-* A placeholder segment must be a valid Ruby identifier preceded by a colon, e.g.
-`:company_id` is allowed, but `:company-id` is not.
-* Routes may not start with a placeholder.
-
-Some examples:
-
-```
-"/dash_board"
-"/widgets/:id"
-"/company/:company_id/locations/:location_id"
-"/"
-```
-
-### Class Naming Conventions
-
-Brut is convention-based, so you are not able to specify the name of the classes
-used to handle routes.  Brut will use the method you called (e.g. `page`) and the
-route your provided to determine the class name.
-
-Some examples:
-
-| Route invocation                              | Expected Class Name(s)             |
-|-----------------------------------------------|------------------------------------|
-| `page "/dashboard"`                           | `DashboardPage`                    |
-| `page "/widgets/:id"`                         | `WidgetsByIdPage`                  |
-| `form "/login"`                               | `LoginForm` and `LoginHandler`     |
-| `action "/delete_widget/:id"`                 | `DeleteWidgetWithIdHandler`        |
-| `path "/tokens/personal/:token, method :put"` | `Tokens::PersonalWithTokenHandler` |
-
-Specifically, the name of the class(es) is/are determined as follows:
-
-* Static segments of the pathname are mapped to namespaces or a class based on converting the path segment to camel-case. For example `new_widget` becomes `NewWidget`.
-* The final static segment in the path represents a class name.  All other static segments represent modules in which the final class is namespaced
-  - If the route is for a page, `Page` is appended to the class name.
-  - If the route is for a form, there are two classes in play, one appended with `Form` and one with `Handler`.
-  - If the route has no form and is just a handler, `Handler` is appended to the class name.
-* Placeholder segments are attached to the previous static segment, augmenting its name:
-  - The placeholder is camel-cased
-  - The placeholder is prefixed with `By` for `page` routes and `With` for all other routes
-  - the prefixed-placeholder is appended to the previous module or class name, e.g. `WidgetsById`
-* These are now connected to form a valid Ruby class name.
-* The route `/` is special and always maps to `HomePage`.
-
-Note that deeply nested routes that contain several placeholders will work, and create complicated classnames.
-
-```ruby
-page "/company/:company_id/location/:location_id"
-# => CompanyByCompanyId::LocationByLocationIdPage
-```
-
-> [!NOTE]
-> All routes can receive query string parameters. These are not factored
-> into the name of the class that will handle the route, but they
-> *are* made available to your Page or Handler.
-
-### Creating URIs for Routes
-
-Because each route is associated with a class, you can use the class to create the route, including any placeholders and query string
-parameters.
-
-The most direct way to do this is with the `routing` method available on each page or handler class:
-
-```ruby
-> WidgetsByIdPage.routing(id: 42)
-# => /widgets/42
-> WidgetsByIdPage.routing(id: 42, compact: true)
-# => /widgets/42?compact=true
-> WidgetsByIdPage.routing(id: 42, compact: true, anchor: "summary")
-# => /widgets/42?compact=true#summary
-> ArchiveWidgetByIdHandler.routing(id: 42)
-# => /archive_widget/42
-```
-
-If you fail to provide the required parameters, `routing` will raise a `Brut::Framework::Errors::MissingParameter` with a message
-explaining the problem.
-
-```ruby
-> begin
-    WidgetsByIdPage.routing
-  rescue Brut::Framework::Errors::MissingParameter => ex
-    puts.ex.message
-  end
-# => Parameter 'id' was not available. Received params: no params.
-#    :id was used as a path parameter for
-#    WidgetsByIdPage (path '/widgets/:id')
-```
-
-`routing` is how you create links to other pages:
-
-```erb
-<a href="<%= DashBoardPage.routing %>">
-  Go to Dashboard
-</a>
-```
-
-> [!NOTE]
-> You can use `routing` to create `<form>` actions, but `Brut::FrontEnd::Components::FormTag`, which we'll discuss in [Forms](/forms), can do this for you.
-
-The `routing` method isn't an abstraction around routes. It's more of a strongly-typed translation.  This means when you change
-something, your app won't route to non-existent routes—it'll blow up with a helpful error.
-
-For example, if you decided that `/dash_board/` should've been called `/account_home`, you would change the value in `app.rb`, then
-rename the class.  At this point, any code that routes to `DashboardPage.routing` will raise a `NameError`.  With sufficient test coverage, you can address everywhere you see the `NameError` and be confident you have changed the name and route successfully.
-
-## Testing
-
-Routes are configuration, so you do not need to test them.  In fact, you can't test them directly. Your end-to-end tests should adequately cover the correct usage of your routes. If you always using `.routing` to generate routes, Ruby's runtime checks will also ensure you have not used a non-existent or invalid route.
-
-## Recommended Practices
-
-Brut does not provide flexibility with routes, nor is logic intended to exist where
-you are declaring them.
-
-### Routes Should be Named for Concepts Anyone Can Understand
-
-If you have an account management page that allows modifying data in a table called `user_preferences`, but everyone just calls it "the account management page", the route should be `/account_management`.
-
-Although routes are primarily for programmers, there's no reason not to name them using the terms everyone involved in your app uses.  This is part of the reason Brut inserts `By` or `With` when there is a placeholder.  It allows you to have a page for all widgets—the "widgets page"—and a page for a specific widget by id—the "widgets by id page".
-
-### Prefer Shallow Routes with a Single Placeholder
-
-The more path segments your route has, and the more placeholders it is, the longer your class name will be and the more you lose the
-connection to reality.  The "company by company id location by location id page" doesn't exactly roll off the tongue.
-
-Life will be easier if you can choose names and routes that have a single placeholder.  Multiple path segments can be useful for namespacing.
-
-### Placeholders Identify Things, Query Strings Search for Things
-
-A query string is for just that: querying. The query string is not for identifying
-things.  That's what URIs are for.
-
-As such, for routes where a specific *thing* is being identified, use route
-placeholders like `/widgets/:id`. When a route is used for searching or locating
-*things*, a query string is better: `/widgets?type=«type»`.
-
-Remember that the query string is *not* part of the class name. The values for the
-query string will be made available to your page or handler.
-
-### Pluralization Is Up to You
-
-The rules Brut uses to determine the class names to handle routes do not rely on pluralization.  You can have a `/widget` route and a `/widgets` route, if that makes sense to your domain and team.  They are both handled by the same set of underlying rules.
-
-## Technical Notes
-
-> [!IMPORTANT]
-> Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut's
-> internals, the source code is always more correct.
-
-_Last Updated Feb 23, 2025_
-
-Brut stores all configured routes in a `Brut::FrontEnd::Routing` object.
-This means that all metadata about a route is available.  You are not intended to interact with this class, but you will note that in
-certain circumstances, the `Brut::FrontEnd::Routing::Route` can be injected into your class.
-
-Brut uses this metadata to create route handlers with Sinatra.  While Brut may not always use Sinatra  under the covers, it does as of
-the writing, so when you call `page "/widgets"`, Brut will call `get "/widgets" do` and pass a block to Sinatra to find the class to
-handle the reqest, create an instance of it, call a method on it, and return the response.
-
-

data/brutrb.com/security.md

@@ -1,102 +0,0 @@
-# Security
-
-As a new framework, Brut has not been battle-tested against potential securitiy exploits.  That said, Brut
-does configure several features to help manage security issues.
-
-## Overview
-
-Web application security is a large topic.  Brut provides a few features out of the box to manage security
-of your app:
-
-* Encrypted sessions
-* Cross-Site Request Forgery (CSRF) protection
-* Content Security Policy headers and tools
-* `bundle audit`
-
-### Encrypted Sessions
-
-Brut uses the `Rack::Session::Cookie` middleware to manage cookies.  They are encrypted with the value of
-the environment variable `SESSION_SECRET`.  This prevents both the website visitor and other websites from
-examining the contents of the cookie.
-
-This means that if Brut places data in there, it can rely on it being safe when fetched later.
-
-Cookie behavior and configuration is currently not configurable.
-
-### CSRF Protection
-
-A [cross-site request forgery](https://owasp.org/www-community/attacks/csrf) happens when a malicious site submits information from their site to a Brut-powered site, assuming it will allow and respect your credentials, potentially initiating an action on the Brut-powered site that you did not intend.
-
-The common way to mitigate this is to require a CSRF token to be included with each form submission. This
-value is generated by the server and included int he user's secure session.  If the form submission's CSRF
-token matches, the request is assumed to be valid.
-
-Brut configures [Rack::Protection::AuthenticityToken](https://sinatrarb.com/rack-protection/) as a
-middleware. Its configuration requires that *all* form submissions include a valid CSRF token, with a few
-exceptions noted in the [Technical Notes](#technical-notes) section below.
-
-To include a valid CSRF token in your [form](/forms), use `Brut::FrontEnd::Components::FormTag` to
-generate your `<form>`.  That's it.
-
-Brut's approach to Ajax requests is to model them as form submissions, so by creating a form using
-`FormTag` and using its [`FormData`](https://developer.mozilla.org/en-US/docs/Web/API/FormData) to submit
-that form with e.g. `fetch`, the CSRF token will be supplied.
-
-> [!NOTE]
-> AJax and CSRF is currently somewhat immature in Brut, so there may be areas where things
-> don't work as you'd expect.
-
-### Content Security Policy headers and tools
-
-[Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) is a way for
-a website to tell the browser what CSS and JavaScript is allowed to execute on the page.  Most web
-frameworks default to a lax or no policy, which makes applying one later difficult.
-
-Brut takes the opposite approach.  By default, Brut configures `Brut::FrontEnd::RouteHooks::CSPNoInlineStylesOrScripts` as an after route hook. This sets the content security poilcy header to disallow all inline stylings (the `style=` attribute) and all inline script tags (e.g. `onclick=`).  In development, inline styles are allowed, since they are convienient when prototyping.
-
-Brut also configures CSP reporting, which is sent into the [instrumentation](/instrumentation) system.
-
-You can control this behavior by changing the `csp_class` and/or `csp_reporting_class` using
-`Brut.container.override` in your `App`.  You can either create your own route hook and use that, or set
-either to `nil` to disable CSP entirely.
-
-### `bundle audit`
-
-The `bin/ci` script provided when you created your Burt app includes  a call to `bundle exec bundle audit
-check --update`, which will audit your RubyGems for versions that have known vulnerabilities.  If any are
-found, `bin/ci` exits nonzero, thus failing your build.
-
-## Testing
-
-In general, you don't want to test any of this unless you've set up something custom or complex. Testing
-security is done more effectively by a third party evaluating your app as a so-called "black box" or
-"opaque box" where its probed for issues without knowing how the app is implemented.
-
-## Recommended Practices
-
-* Do not disable CSRF protection.
-* Do not disable your content security policy.  Use Brut's built-in and design your app to not require inline styles or scripts.  It's much easier to not do this in the first place than to try to unwind it later.
-* Do not ship your app if `bundle audit` finds vulnerabilities.
-
-## Technical Notes
-
-> [!IMPORTANT]
-> Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut's
-> internals, the source code is always more correct.
-
-_Last Updated June 13, 2025_
-
-### CSRF Protection
-
-CSRF protection is not required for *Brut-owned paths*, as defined by 
-`Brut::FrontEnd::Middlewares::AnnotateBrutOwnedPaths`.  The reason for this is that these paths
-semantically should not be HTTP GETs, but are also not form submissions.  They are currently used for
-locale detection and instrumentation, which we believe are OK to allow without CSRF protection.
-
-This may change in the future.
-
-### Encrypted Sessions
-
-Session cookies are set to expire after 1 year and use the value `Lax` for
-[`SameSite`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies#controlling_third-party_cookies_with_samesite). "Lax" allows other sites to submit the Brut-powered site's cookies, but only if the user navigates to the site.  They are not sent if another site submits an Ajax request.  We feel this is the right tradeoff betweeen usability and security.
-

data/brutrb.com/seed-data.md

@@ -1,63 +0,0 @@
-# See Data for Development
-
-In Brut, *seed data* is data you set up for the purposes of doing local development.  It is *not* for managing
-production data and is not used for tests.
-
-## Overview
-
-Seed data lives in `app/src/back_end/data_models/seed`.  You can create as many files in here as you like. Each
-should contain a class that extends `Brut::BackEnd::SeedData` and implements `seed!`.  By doing this, the class
-is regsitered with Brut and when you run `bin/db seed` all the classes are created and `seed!` is called.
-
-FactoryBot will be set up for you, so you can call `FactoryBot.create` to create the data.
-
-For example, here is how we might create two accounts, one deactivated, in the same organization:
-
-```ruby
-# app/src/back_end/data_models/seed/all_seed_data.rb
-class AllSeedData < Brut::BackEnd::SeedData
-  include FactoryBot::Syntax::Methods
-
-  def seed!
-    organization     = create(:organization)
-    active_account   = create(:account,
-                              organization:,
-                              email: "pat@example.com")
-    inactive_account = create(:account, :inactive,
-                              organization:,
-                              email: "chris@example.com")
-  end
-end
-```
-
-You can store other data here, such as a CSV, if you want to load data organized in another way.  Seed data will
-only ever be loaded in development, so you can organize it however you like.
-
-## Testing
-
-You do not need to test your seed data. Presumably, you will be using your app in development, and this will be
-sufficient to determine if your seed data is fit for purpose.
-
-## Recommended Practices
-
-* Use FactoryBot as this is consistent with your tests
-* Use literal values for anything relevant to local development. In the example above, the two email addresses are important, presumably because you'd be using those to login. The organization name, however, is irrelevant, so we allow Faker to come up with a name.
-* Use local variables as documentation. In the example above, there's no need to set `active_account` or
-`inactive_account`, but doing so makes it clear what those objects are for.
-* Ensure all seed data classes are independent from one another, as the order of their exeuction cannot be guaranteed.
-
-## Technical Notes
-
-> [!IMPORTANT]
-> Technical Notes are for deeper understanding and debugging. While we will try to keep them up-to-date with changes to Brut's
-> internals, the source code is always more correct.
-
-_Last Updated May 8, 2025_
-
-All seed data is loaded in one transaction.  This means that if any class' seed data fails, no data will be
-written.
-
-Seed data also is not assumed to be idempotent. If you run it twice, you will likely get an error.  Because 
-[your dev database is ephemeral](/database-schema#ephemeral-dev-database), you can always recreate your dev
-database via `bin/db rebuild && bin/db seed`.
-

data/brutrb.com/space-time-continuum.md

@@ -1,81 +0,0 @@
-# Space/Time Continuum - Making Sense of Times and Time Zones
-
-Time zones are the worst.  But they are fact of life.  This means that answer a question like "what is the date?" or "is it Monday?" are not that easy to answer. Brut tries to help.
-
-## Timezones Outside of Web Requests
-
-For back-end code, storing dates to the database, etc., Brut falls back to the normal Ruby app mechanisms for determining the "current time zone", which is to say, it super-duper depends.  The system, the database, and Ruby can all configure a time zone that is in effect when dates are parsed or stored.
-
-The main way to deal with this is in how [Brut manages your database schema](/database-schema), which is to say that it defaults to using `timestamp with time zone` and encourages you to do the same. 
-
-What this data type means is if your system is set to UTC, stores a timestamp, then restarts with the time zone set to America/Los\_Angeles, that timestamp will be read back without ambiguity.  If you use `timestamp without time zone` (or SQL's standard `timestamp`), this will not be the case.
-
-All this is to say, if you use `timestamp with time zone`, you should generally not have to worry about this.
-Just be careful when serializing these values.
-
-## Timezones for Sessions
-
-Depending on what your app does, you may need to show dates or times to the site visitor.  And you'll probably
-want to show those in their time zone.  Brut can help with this.
-
-As mentioned in [Flash and Session](/flash-and-session), the session provides access to timezone information.
-Brut also provides a `Clock` class that represents the current date and time in the current session's time zone.
-
-There are two ways to determine a visitor's time zone: you can ask them, or you can ask their browser.
-
-### Getting Timezone from the Browser
-
-The default `<head>` section of your app's `DefaultLayout` will include the Brut-provided custom element
-`<brut-locale-detection>`. This HTML custom element is configured to communicate the browser's locale and
-timezone back to Brut at the URL `/__brut/local_detection`, which is handled by
-`Brut::FrontEnd::Handlers::LocaleDetectionHandler`.
-
-The custom element uses `Intl.DateTimeFormat().resolvedOptions().timeZone` to determine the browser's timezone
-and sends this back to Brut. Whatever this value is, it will be set in the session as `timezone_from_browser`.
-When you ask the session for the `timezone_from_browser`, Brut will attempt to locate a `TZInfo::Timezone` with
-that name. If it finds one, that is returned.  Otherwise, `nil` is returned.
-
-This is only part of how Brut determines the session's time zone.
-
-### Getting the Session's Timezone
-
-If you ask the session instead for `timezone`, and it has not been set explicitly, 
-Brut will first check `timezone_from_browser`. If it's not `nil`, it's returned. If it *is* `nil`, the timezone
-whose name is in `ENV['TZ']` is returned, unless that is missing or invalid, in which case UTC is returned.
-
-If you have a way to ask the user what their timezone is, you can set it via `session.timezone=`. If you have
-done this, *that* value is returned instead of the above logic.
-
-Note that in all cases, the timezone that is serialized into the session is the name. This means it's technically
-possible for the name to be valid when stored and invalid when read, if you have updated the `tzinfo` gem and
-something changed (this should be exceedingly rare).
-
-Therefore, it's recommended that if you have asked the visitor their preferred time zone, you store that
-somewhere in the database, so you can detect when the value from the session has drifted.
-
-### Using the Timezone
-
-With a `TZInfo::Timezone` object, you can certainly create a Ruby `Time` object via
-`timezone.to_local(Time.new)`.  However, you don't have to do this.  By [keyword injecting](/keyword-injection)
-`clock:`, you will get an instance of `Clock`, primed with the value of `session.timezone` as its timezone.
-
-The `Clock` responds to `now` and `today`, and will return the current timestamp and current date, respectively, in the visitor's time zone.  This means that if your view code does something like `l(clock.now, format: :date)`, it will show the current time in the visitor's time zone.
-
-This, coupled with the use of `timestamp with time zone`, means these values can be safely sent to the back-end
-to be stored in the database, and conversion is not necessary.
-
-## Testing
-
-If your app makes heavy use of timezone-based timestamps or dates, you are encouraged to test this logic. `Brut::SpecSupport::ClockSupport` (included by default in page, component, and handler tests) provides helper methods to manipulate and use `Clock` instances.  You should not need to mock time or use something like Timecop.
-
-If your tests just need a clock, or a clock at a time, regardless of time zone, you can use `real_clock` or
-`clock_at(now:)` to pass into your pages, components, and handlers.  These will be set at UTC.
-
-If your tests require a particular timezone, you may use `clock_in_timezone_at(timezone_name:, now:)`. The
-timezone name is from `tzinfo`'s database. `clock_in_timezone_at` will raise an error if given an invalid
-timezone.  `now:` is a string that will be parsed as a `Time`.
-
-If you are testing something that is sensitive to time, but you do not have access to the clock, `Brut::SpecSupport::SessionSupport` provides `empty_session`, which returns a session object on which you can call `timezone=`.  Beyond this, you may need to provide hooks for setting the time, for example via a query string parameter.
-
-
-