brut 0.0.20 → 0.0.22

data/doc-src/javascript.md

@@ -1,265 +0,0 @@
-# JavaScript and Front End Behavior
-
-Brut does not prevent you from using any front-end framework you like.  You can certainly install React and reference it in
-`app/src/front_end/javascript/index.js`.  However, Brut would like to humbly request that you not do this.
-
-Brut is based around server-generated HTML and the web platform.  This means that Brut would like you to use custom elements for any
-client-side behavior you need, and to do so with progressive enhancement.
-
-To that end, Brut includes BrutJS, which is a set of custom elements and ancillary JavaScript you can use to build client-side
-behavior.
-
-By default, your `index.js` will look like this:
-
-    import { BrutCustomElements } from "brut-js"
-    import Example from "./Example"
-
-    document.addEventListener("DOMContentLoaded", () => {
-      BrutCustomElements.define()
-      Example.define()
-    })
-
-`BrutCustomElements` and `BrutCustomElements.define()` will set up the custom elements bundled with Brut.  `Example` shows you how to
-build your own custom elements.
-
-## Some Useful Brut Elements
-
-Please refer to BrutJS's documentation for everything that is included, but here are a few highlights that you will find usefule.
-
-### Client Side Form Support
-
-{file:doc-src/forms.md Forms} outlines Brut's server-side form support.  Brut provides custom elements to allow you to unify client
-and server side constraint validations, and make the process a bit easier to manage with CSS.
-
-First, surrounding a form with a `<brut-form>` will place `data-submitted` onto the `<form>` *only* when the user attempts to submit the
-form.  You can use this in your CSS to prevent showing error messages before a user has submitted.
-
-Second, you can use `<brut-cv-messages>` and `<brut-cv>` to control the error messages that are shown when the browser detects
-constraint violations.  This works with `<brut-i18n-translation>` to show translated strings.
-
-Consider this ERB
-
-    <label>
-      <%= 
-        component(
-          Brut::FrontEnd::Components::Inputs::TextField.for_form_input(form:, input_name: :name)
-        )
-      %>
-      <span>Name</span>
-      <%= constraint_violations(form:,input_name: :name) %>
-    </label>
-
-{Brut::FrontEnd::Component::Helpers#constraint_violations} will render the built-in {Brut::FrontEnd::Components::ConstraintViolations}
-component.  Along with `for_form_input`, the following HTML will be generated:
-
-    <label>
-      <input type="text" name="name" required>
-      <span>Name</span>
-      <brut-cv-messages input-name="name">
-      </brut-cv-messages>
-    </label>
-
-When any element of the form causes a validity event to be fired, `<brut-form>` will locate the appropriate `<brut-cv-messages>` and
-insert the appropriate `<brut-cv>` elements.  Suppose the user submitted this form. Since the `name` input is required, the form
-submission wouldn't happen, and the resulting HTML would look like so:
-
-    <label>
-      <input type="text" name="name" required>
-      <span>Name</span>
-      <brut-cv-messages input-name="name">
-        <brut-cv input-name="name" key="valueMissing"></brut-cv>
-      </brut-cv-messages>
-    </label>
-
-Now, assuming your layout used `<brut-i18n-translation>` custom elements, for example like so:
-
-    <brut-i18n-translation key="general.cv.fe.valueMissing">%{field} is required</brut-i18n-translation>
-
-The `<brut-cv>` custom element will find this and replace its `textContent`, resulting   in the following HTML:
-
-    <label>
-      <input type="text" name="name" required>
-      <span>Name</span>
-      <brut-cv-messages input-name="name">
-        <brut-cv input-name="name" key="valueMissing">
-          This field is required
-        </brut-cv>
-      </brut-cv-messages>
-    </label>
-
-You can now use CSS to style client-side validations *and* control the content shown to the user.  If there are server-side constraint
-violations, The `ConstraintViolations` component would render them (as well as server-generated translations), for example if a name
-was given, but it's taken already, `ConstraintViolations` would render this HTML:
-
-    <label>
-      <input type="text" name="name" required value="foo">
-      <span>Name</span>
-      <brut-cv-messages input-name="name">
-        <brut-cv input-name="name" server-side>
-          This value has been taken
-        </brut-cv>
-      </brut-cv-messages>
-    </label>
-
-### Confirming Dangerous Actions
-
-Often, you want to use JavaScript to confirm the submission of a form whose action is considered dangerous to the user or hard to undo.
-This can be achieved with `<brut-confirm-submit>`
-
-    <form>
-      <input type="text" name="name" required>
-      <brut-confirm-submit message="This will delete the app">
-        <button>Delete App</button>
-      </brut-confirm-submit>
-    </form>
-
-By default, this will use the browser's built-in `window.confirm`, however you can also use a `<dialog>` element as well.
-
-If the generated HTML includes a `<dialog>`, you can surround it with `<brut-confirmation-dialog>` to indicate it should be used for
-confirmation.  The `<dialog>` should have an `<h1>` where the message will be placed and two buttons, one with `value="ok"` and one
-with `value="cancel"`.
-
-
-    <brut-confirmation-dialog>
-      <dialog>
-        <h1></h1>
-        <button value="ok">Do It!</button>
-        <button value="cancel">Nevermind</button>
-      </dialog>
-    </brut-confirmation-dialog>
-
-When the `<brut-confirm-submit>`'s `<button>` is clicked, this `<dialog>` is shown with the message inserted.  If the user hits the
-button with `value` of `"ok"`, the form submission goes through. Otherwise, it doesn't.  The dialog is then hidden.
-
-### Ajax Form Submission
-
-To submit a form via Ajax, you can use `<brut-ajax-submit>` around the `<button>` that should submit the form with Ajax.  This element
-attempts to provide a fault-tolerant user experience and will set various attributes on itself to allow you to change styling during
-the various phases of the request.
-
-If the submission works, it will fire a `brut:submitok` event that your custom code can receive and do whatever makes the most sense
-in that case.
-
-If the submission fails with a 422, your server should return a series of `<brut-cv>` custom elements.  If it does, this will be
-inserted into the correct `<brut-cv-messages>` elements to dynamically create error messages.  The element will then fire a
-`brut:submitinvalid` event you can catch and handle to do something custom.
-
-If the submission times out or fails in some other way, Brut will submit the form the old-fashioned way.
-
-### Client-Side, Accessible Tabs
-
-Many UIs involve a set of tabs that switch between different views.  While HTML has no built-in support for this, Brut's `<brut-tabs>`
-custom element can captialize on the various ARIA roles required to design a tabbed interface and provide all the JavaScript behavior
-necessary.  See that element's documentation for an extended example.
-
-## Building Your Own Custom Elements
-
-Because custom elements are part of the web platform, Brut encourages you to use them to add client-side behavior.  As a
-demonstration of this working, there is an `Example` element set up when you created your app.  Assuming your app's prefix was `cc`
-when you created it, the `Example` element works like so:
-
-      <cc-example transform="upper">
-        Here is some text
-      </cc-example>
-
-When the browser renders this—assuming JavaScript is enabled—it will render the following:
-
-      <cc-example transform="upper">
-        HERE IS SOME TEXT
-      </cc-example>
-
-You wouldn't want to do this, but this simple element demonstrates both how to make your own and that custom elements in your app are
-properly configured.
-
-This element is very close to a vanilla custom element, but it extends `BaseCustomElement`, which is provided by BrutJS, which includes
-z few quality-of-life improvements. Let's walk through the code.
-
-First, we extends `BaseCustomElement` (which extends `HTMLElement`) and define a static attribute, `tagName` that will be the
-element's tag name you can use in your HTML:
-
-    import { BaseCustomElement } from "brut-js"
-
-    class Example extends BaseCustomElement {
-      static tagName = "cc-example"
-
-Next, we'll define the attributes of our element using `observedAttributes`, which is part of the custom element spec (and not
-specific to BrutJS):
-
-      static observedAttributes = [
-        "transform",
-        "show-warnings",
-      ]
-
-The `show-warnings` attribute, if placed on the element's HTML, configures `this.logger` from `BaseCustomElement` to allow output of debug messages. This allows you to easily debug your element's behavior in development, but remove them from production.  We'll see that in a bit.
-
-Next, we'll set a private attribute to hold a default value for the `transform` HTML attribute. It can be named anything:
-
-      #transform = "upper"
-
-Now, we want to know when `transform` changes.  Normally, you'd implement `attributeChangedCallback` and check its `name` parameter.
-`BaseCustomElement` allows you to do this more directly by creating a `xxxChangedCallback` method for each attribute in
-`observedAttributes` that you want to know about.  For `transform`, that means implementing `transformChangedCallback`:
-
-      transformChangedCallback({newValue}) {
-        this.#transform = newValue
-      }
-
-Next, we implement the bulk of the element's behavior.  Because there are many lifecycle events that may require modifying the
-element, `BaseCustomElement` consolidates all of those events and calls the method `update()`.  `update()` should be idempotent
-and should examine the element's state (as well as the document's, if necessary) and update the element however it makes sense.
-
-For this example, we want to grab the content, examine the value for `transform` and change the content:
-
-      update() {
-        const content = this.textContent
-        if (this.#transform == "upper") {
-          this.textContent = content.toLocaleUpperCase()
-        }
-        else if (this.#transform == "lower") {
-          this.textContent = content.toLocaleLowerCase()
-        }
-        else {
-          this.logger.info("We only support upper or lower, but got %s",this.#transform)
-        }
-      }
-
-Notice the last line where we call `this.logger.info`.  If `show-warnings` is omitted from the HTML, this message isn't shown anywhere. If `show-warnings` *is* present, this message will show up in the console.  This can be useful for understanding why your element isn't working.
-
-Lastly, we export the class:
-
-    }
-    export default Example
-
-By virtue of having extended `BaseCustomElement`, the static `define()` method will set it up as a custom element with the browser.
-
-## Testing Custom Elements
-
-Sometimes, system tests are sufficient to ensure your custom element code is working.  If not, Brut (via BrutJS) provides a way to
-test your element in isolation.
-
-These tests use JSDom which, while not perfect, allows the tests to run reasonably quickly.  Each test begins with `withHTML` to
-define the markup that is being tested.  This is followed by `test` which accepts a function that performs the test.
-
-Rather than have a DSL to provide access to your element's state, you can use the browser's API (as provided by JSDom) to check
-whatever it is you need to check:
-
-    import { withHTML } from "./SpecHelper.js"
-
-    describe("<cc-example>", () => {
-      withHTML(`
-      <cc-example>This is some Text</cc-example>
-      `).test("upper case by default", ({document,assert}) => {
-        const element = document.querySelector("cc-example")
-        assert.equal(element.textContent,"THIS IS SOME TEXT")
-      })
-      withHTML(`
-      <cc-example transform="lower">This is some Text</cc-example>
-      `).test("lower case when asked", ({document,assert}) => {
-        const element = document.querySelector("cc-example")
-        assert.equal(element.textContent,"this is some text")
-      })
-    })
-
-Note that `test`'s second argument—the function that performs the test—is called with objects you can use to perform the test. In this
-case, the `document` is passed in as-is the `assert` method.
-

data/doc-src/pages.md

@@ -1,210 +0,0 @@
-# Pages and Components
-
-A website is made up of pages.  Even a web *app* has pages.  Thus, the most basic way to create dynamic behavior with Brut is the
-*page*.  In Brut, a page is a URL, a subclass of {Brut::FrontEnd::Page}, and an ERB template.  The template is rendered in the context
-of an instance of the class whenever the URL is requested.
-
-## Overview of Rendering Pages
-
-In your `app.rb`, you first declare a page using the {Brut::SinatraHelpers::ClassMethods#page} method (inside the block given to {Brut::Framework::App.routes}):
-
-    class App < Brut::Framework::App
-
-      routes do
-
-        page "/sign_in"
-      end
-    end
-
-The name of the route must start with a `/` and the rest of the route determines the name of the page.  In the example above, Brut
-will expect to find a class named `SignInPage`, which should be located in `app/src/front_end/pages`.  You can create it with
-`bin/scaffold`:
-
-    > bin/scaffold page SignInPage
-
-The page class must subclass {Brut::FrontEnd::Page}.  You write a constructor to accept whatever your page needs to assemble the data
-needed to render it.
-
-The HTML is generated based on an ERB file located in `app/src/front_end/pages`.  In this example, that's
-`app/src/front_end/pages/sign_in_page.html.erb`.  That ERB is executed with an instance of the page class as context.  That means you
-can references any methods or ivars.
-
-## Creating a Page Class
-
-{Brut::FrontEnd::Page#render} is called by Brut and expects to receive HTML, which it will send as the body of the response. `render`
-manages the ERB rendering, so the bulk of your page's logic will be in other methods.  The constructor is where any data you need is
-provided.
-
-A page's `initialize` method must accept only keyword arguments and those keywords are used by Brut to determine what data needs to be
-passed in.  This technique, called *{file:doc-src/keyword-injection.md Keyword Injection}*, is used in several other places in Brut.
-
-When the page's URL is requested, an instance of your page class is created, passing in the values needed.  Beyond that, however, your page class is a normal Ruby class. You can save data to instance variables, implement attributes or other methods. Basically, whatever logic your page needs to render will exist in the page class.
-
-## Implementing Your ERB
-
-ERB is part of the Ruby standard library that allows the creation of dynamic templates.  Brut's ERB is close to this implementation, but has a few additional features that make working with HTML a bit safer.
-
-### Your Page is the Only Context
-
-The instance of your page class is the only context available to the ERB.  There is no set of global helpers that are injected, nor
-are there any modules added when the page is rendered.  Anything you need to do in your ERB must be available to the page class you've
-created.
-
-The reason for this is to keep things simple.  If your page's HTML needs access to a lot of stuff, your page class will be the source
-of truth as to where that stuff comes from.  You will always be able to figure out where methods are defined by looking at the page
-class or any of its ancestors.  You are free to `include` as many modules as you like, or dump lots of methods into your `AppPage`
-base class. But you don't have to.
-
-### All Strings are HTML-Escaped
-
-Any instance of a `String` is HTML-escaped by Brut before being inserted into the HTML being generated by the ERB.  This is, generally, what you want to have happen.  If you have a string that you believe is safe and does not need to be escaped, you can prevent HTML-escaping in one of two ways:
-
-* Call {Brut::FrontEnd::Component#html_safe!} on the string
-
-        <%= html_safe!(get_value) %>
-
-* Wrap the string in a {Brut::FrontEnd::Templates::HTMLSafeString}.
-
-        def get_value
-          Brut::FrontEnd::Templates::HTMLSafeString.from_string(some_value)
-        end
-
-  This is what `html_safe!` does and this is what Brut does internally. Brut doesn't monkey-patch `String`. A `String` is always
-  considered unsafe, and an `HTMLSafeString` is always considered safe.
-
-Both of these methods are verbose, but this is on purpose.  You generally don't want un-escaped HTML going into your HTML, but if you
-do, you may find it better to create a component (see below), or use {Brut::FrontEnd::Component::Helpers#html_tag} to generate markup.
-
-### Pages Have Layouts
-
-The page's ERB is rendered in the context of a *layout*.  A Layout works similar to how it works in Rails. It's intended to hold HTML
-needed by every page of your app. A minimal layout might look like so:
-
-    <!DOCTYPE html>
-    <html>
-      <head>
-        <meta charset="utf-8">
-        <%= component(Brut::FrontEnd::Components::PageIdentifier.new(self.page_name)) %>
-        <link rel="preload" as="style" href="<%= asset_path('/css/styles.css') %>">
-        <link rel="stylesheet"         href="<%= asset_path('/css/styles.css') %>">
-        <script defer src="<%= asset_path('/js/app.js') %>"></script>
-      </head>
-      <body>
-        <%= yield %>
-      </body>
-    </html>
-
-The layout is rendered in the context of the page class, so every page must provide whatever features are needed by the layout. This
-is usually done by adding globally-used functions to `AppPage`, which is the base class of all your app's pages.
-
-A page can use another layout by overriding {Brut::FrontEnd::Page#layout}.  The string returned must match a file in
-`app/src/front_end/layouts/`.
-
-### There Are No Partials
-
-Rails partials are not part of ERB, and Brut does not include this feature. Instead, you would use *Components*.
-
-## Decompose and Re-Use with Components
-
-*Components* in Brut are very similar to the View Components library, though somewhat simpler.  A component is a class and an ERB
-template.  That template is rendered in the context of an instance of the class.  That class is created the same way a page is and has
-a `render` method that works just like a page's.
-
-This is all because {Brut::FrontEnd::Page} extends {Brut::FrontEnd::Component}.  A page adds the concept of a layout, but generally a
-page and a component are the same thing.
-
-### Using Components
-
-The main difference from your perspective is that generally *you* create instances of components.  This means that your page must have
-access to any data a component needs.  When you've created your component instance, use {Brut::FrontEnd::Component#component} to
-render it:
-
-    <%= component(Button.new(type: :danger, label: "Cancel Subscription")) %>
-
-### Components with Templates
-
-The most common way to use a component is with an ERB template. It is expected to be in `app/src/front_end/components`.  For the
-hypothetical `Button` component above, Brut would expect `app/src/front_end/components/button.html.erb` to exist as a template.
-
-Just like a page, the component's ERB is rendered in the context of the component only.
-
-Sometimes, components are simple enough that you don't need HTML.
-
-### Components That Render Themselves
-
-While overriding `render` in a page is generally discouraged, {Brut::FrontEnd::Component#render} can be overridden if you want to
-generate HTML yourself.  The best way to do that is with {Brut::FrontEnd::Component::Helpers#html_tag}, though you can always return a
-`String` or {Brut::FrontEnd::Templates::HTMLSafeString} that you've created yourself. Just remeber that all `String` instances will be
-HTML-escaped.
-
-As an example, here is how you might have a Markdown component that renders Markdown as HTML:
-
-    class MarkdownComponent < AppComponent
-      def initialize(markdown:)
-        @markdown = markdown
-        @renderer = Redcarpet::Markdown.new(
-          Redcarpet::Render::HTML.new(
-            filter_html: true,
-            no_images: true,
-            no_styles: true,
-            safe_links_only: true,
-          ),
-          fenced_code_blocks: true,
-          autolink: true,
-          quote: true,
-        )
-      end
-
-      def render
-       html_safe!(@renderer.render(@markdown.to_s))
-      end
-    end
-
-
-### Global Components
-
-While a component is just a class with an initializer, sometimes you need a component that is generally useful on any page, but that
-you don't want to initialize.  For example, if your component needs access to the flash, but your page does not, you don't want your
-page to require a flash just to pass to the component.  In that case, a *global component* can be used and Brut will instantiate it.
-
-{Brut::FrontEnd::Component#component} can be given a class, and Brut will use keyword injection to create it.  Consider a generic
-flash component:
-
-    class GlobalFlash < AppComponent
-
-      attr_reader :flash
-
-      def initialize(flash:)
-        @flash = flash
-      end
-    end
-
-You can use this anywhere like so:
-
-    <%= component(GlobalFlash) %>
-
-Because the flash is availble from the {Brut::FrontEnd::RequestContext}, Brut can create this component when needed.
-
-## Testing Pages and Components
-
-Pages and Components are classes with a constructor you create and a well-defined primary method called `render`.  This means you can
-test them conventionally, since they can be directly created in your tests.
-
-That said, you likely want to test the generated HTML and not the methods of the class.  All tests of a page or component have the
-methods in {Brut::SpecSupport::ComponentSupport} available.  Of particular interest is
-{Brut::SpecSupport::ComponentSupport#render_and_parse}.
-
-This method accepts an instance of a page or component, parses the resulting HTML with Nokogiri, and returns a
-{Brut::SpecSupport::EnhancedNode}, which wraps a `Nokogiri::XML::Node` or `Nokogiri::XML::Element`, depending on what was parsed.  You
-can then use Nokogiri's API locate elements and assert on them.
-
-To keep close to the web platform, it's recommended to use CSS selectors either via {Brut::SpecSupport::EnhancedNode#e} or {Brut::SpecSupport::EnhancedNode#e!} (both of which wrap Nokogiri's `css` method).
-
-Instead of creating another API for accessing HTML content, the Nokogiri API should be used directly.  You can create custom matchers
-as needed for common assertions.  Brut includes a few that you will find useful:
-
-* `have_link_to`
-* `have_html_attribute`
-* `have_i18n_string`
-
-

data/doc-src/route-hooks.md

@@ -1,59 +0,0 @@
-# Route and Page Hooks
-
-Route and page hooks allow you to perform logic or redirect the visitor before a page is rendered or action handled.
-
-## Route Hooks
-
-Route hooks are objects that are run before or after a request has been handled. They are useful for setting up cross-cutting code
-that you don't want to have inside a page or handler.
-
-To use one, call either {Brut::Framework::App.before} or {Brut::Framework::App.after}, passing it the *name* of a class to use as the
-hook (i.e. a `String`).
-
-Then, implement that class, extending {Brut::FrontEnd::RouteHook}, and provide either {Brut::FrontEnd::RouteHook#before} or {Brut::FrontEnd::RouteHook#after}.  As discussed in {file:doc-src/keyword-injection.md Keyword Injection}, your hook can be passed some managed values to allow it to work.
-
-In general, a hook will allow the request to continue or not, but using one of the following methods as the return value:
-
-* {Brut::FrontEnd::HandlingResults#redirect_to} to redirect the user instead of rendering the page or handling the request.
-* {Brut::FrontEnd::HandlingResults#http_status} to return an HTTP status instead of rendering the page or handling the request.
-* {Brut::FrontEnd::RouteHook#continue} to proceed with the request.
-
-## Page Hooks
-
-Sometimes, the behavior you want to manage before a page is rendered is specific to a page and not cross-cutting. Because a page
-exepcts to render HTML, you cannot easily put such code in your page class.
-
-If you implement {Brut::FrontEnd::Page#before_render}, you can skip page rendering entirely and redirect the user or send an error.  A
-good example of this would be a set of admin pages where the logged-in site visitor must possess some roles in order to see the page.
-
-A page hook expects one of these return values:
-
-* `URI` - redirect the visitor instead of rendering the page.
-* {Brut::FrontEnd::HttpStatus} - Send the browser this status code instead of rendering the page.
-* Anything else - render the page as normal
-
-Thus, the lifecycle of a page is:
-
-1. "Before" Route Hooks
-2. Page Initializer, injected as described in {file:doc-src/keyword-injection.md}
-3. Page's `before_render`, called with no arguments.
-4. Page's ERB generates HTML
-5. "After" Route Hooks
-
-## Handler Hooks
-
-Like page hooks, handler hooks are called before handling logic.  Implement `before_handle`.  It's arguments must be a subset of the
-arguments passed to `handle`.  Thus, any value needed by `before_handle` must be declared as a keyword argument to `handle` as well.
-
-If `before_handle` returns `nil`, `handle` is then called.  Otherwise, `handle` is skipped and the return value of `before_handle` is
-interpreted as the return value of `handle`. See {Brut::FrontEnd::Handler#handle}.
-
-This makes the lifecycle of a handler as such:
-
-1. "Before" Route Hooks
-2. Handler Initializer, called with no argument.
-3. Handler's `handle!`, injected with arguments as described in {file:doc-src/keyword-injections.md}
-   1. `handle!` calls `before_handle`, passing the arguments in.
-   2. `handle!` calls `handle`, passing the arguments in.
-4. "After" Route Hooks
-

data/lib/brut/front_end/components/inputs/select.rb

@@ -1,117 +0,0 @@
-# Renders an HTML `<select>`.
-class Brut::FrontEnd::Components::Inputs::Select < Brut::FrontEnd::Components::Input
-  # Creates the appropriate select input for the given {Brut::FrontEnd::Form} and input name.
-  # Generally, you want to use this method over the initializer.
-  #
-  # @param [Brut::FrontEnd::Form} form The form that is being rendered. This method will consult this class to understand the requirements on this select so its HTML is generated correctly.
-  # @param [String] input_name the name of the input, which should be a member of `form`
-  # @param [Array<Object>] options An array of objects represented what is being selected. These can be any object and are ideally whatever domain object or data type you want on the backend to represent this selection.
-  # @param [Object] selected_value The currently-selected value for the select. Can be `nil` if nothing is selected.
-  # @param [Symbol|String] value_attribute the name of an attribute or no-parameter method that can be called on objects inside `options` to get the value to use in the select input.  This should be unique amongst the options, and is usually an id.
-  # @param [Symbol|String] option_text_attribute the name of an attribute or no-parameter method that can be called on objects inside `options` to get the actual text of the option shown to the user.  This should probably allow for I18n.
-  # @param [Integer] index if this input is part of an array, this is the index into that array. This is used to get the input's value.
-  # @param [Hash] html_attributes any additional HTML attributes to include on the `<select>` element.
-  # @param [false|true|Hash] include_blank configure how and if to include a blank element in the select. If this is false, there will be no blank element. If it's `true`, there will be one with no value nor text.  If this is a `Hash` it must contain a `value:` key and `text_content:` key to be used as the `value` attribute and option text content, respectively.
-  def self.for_form_input(form:,
-                          input_name:,
-                          options:,
-                          selected_value:,
-                          include_blank: false,
-                          value_attribute:,
-                          option_text_attribute:,
-                          index: nil,
-                          html_attributes: {})
-    html_attributes = html_attributes.map { |key,value| [ key.to_sym, value ] }.to_h
-    default_html_attributes = {}
-    index ||= 0
-    input = form.input(input_name, index:)
-    default_html_attributes[:required] = input.required
-    if !form.new? && !input.valid?
-      default_html_attributes["data-invalid"] = true
-      input.validity_state.each do |constraint,violated|
-        if violated
-          default_html_attributes["data-#{constraint}"] = true
-        end
-      end
-    end
-    name = if input.array?
-             "#{input.name}[]"
-           else
-             input.name
-           end
-    Brut::FrontEnd::Components::Inputs::Select.new(
-      name: name,
-      options:,
-      selected_value:,
-      value_attribute:,
-      option_text_attribute:,
-      include_blank:,
-      html_attributes: default_html_attributes.merge(html_attributes)
-    )
-  end
-  # Create the element. See {.for_form_input} for documentation on these parameters.
-  def initialize(name:,
-                 options:,
-                 include_blank: false,
-                 selected_value:,
-                 value_attribute:,
-                 option_text_attribute:,
-                 html_attributes:)
-    @options               = options
-    @include_blank         = IncludeBlank.from_param(include_blank)
-    @selected_value        = selected_value
-    @value_attribute       = value_attribute
-    @option_text_attribute = option_text_attribute
-    @html_attributes      = html_attributes
-
-    @html_attributes[:name] = name
-  end
-
-  def view_template
-    select(**@html_attributes) {
-      if @include_blank
-        option(**@include_blank.option_attributes) {
-          @include_blank.text_content
-        }
-      end
-      options = @options.each do |option|
-        value = option.send(@value_attribute)
-        option_attributes = { value: value }
-        if value == @selected_value
-          option_attributes[:selected] = true
-        end
-        option(**option_attributes) {
-          option.send(@option_text_attribute)
-        }
-      end
-    }
-  end
-private
-
-  # @!visibility private
-  class IncludeBlank
-    attr_reader :text_content, :option_attributes
-    def self.from_param(include_blank)
-      if !include_blank
-        return nil
-      else
-        self.new(include_blank)
-      end
-    end
-    def initialize(include_blank)
-      if include_blank == true
-        @text_content = ""
-        @option_attributes = {}
-      elsif include_blank.kind_of?(Hash)
-        if include_blank.key?(:value) && include_blank.key?(:text_content)
-          @text_content = include_blank[:text_content]
-          @option_attributes = { value: include_blank[:value] }
-        else
-          raise ArgumentError, "when include_blank: is a Hash, it must include both :value and :text_content as keys. Got: #{include_blank.keys.join(", ")}"
-        end
-      else
-        raise ArgumentError,"include_blank: was a #{include_blank.class}. It should be true, false, nil, or a Hash"
-      end
-    end
-  end
-end