القائمة
Slim template formatting and best practices for Folio components and views. Use when writing or editing .slim templates, reviewing Slim formatting, or when the user asks about Slim conventions, multi-line attributes, or template structure in Folio.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Folio and host-app testing conventions. Use when adding, changing, debugging, or reviewing tests, test helpers, factories/fixtures, mocks, stubs, ViewComponent tests, JavaScript behavior tests, integration/system coverage, or files under test/ and packs/*/test.
Folio “HTML over wire” JSON APIs: controllers use render_component_json so the response body is JSON with a string "data" key holding rendered ViewComponent HTML; JavaScript uses Folio.Api.apiGet/apiPost and response.data, not pure domain JSON for client-side rendering. Use when adding or changing render_component_json, console/API endpoints that return component fragments, or consumers of response.data as HTML.
JavaScript conventions for Folio: ES6+, StandardJS linting, DOM APIs, Folio.Api fetch wrappers, debounce/throttle, flash events, and when to use Stimulus. Use when writing or editing .js files, adding behavior to components, or when the user asks about JavaScript patterns in Folio.
Folio optional pack boundary and namespace rules. Use when editing files in optional pack directories, adding pack controllers/components/models/lib code, wiring routes to pack code, or moving reusable behavior between a host app, the Folio engine, and an optional pack, including Packwerk verification.
Build or change Folio SimpleForm inputs and extensions: app/inputs classes, SimpleForm::Inputs overrides, register_stimulus wiring, input_controls, custom_html, standalone input JS/Sass assets, and rendered HTML tests.
Folio Stimulus conventions: controller registration, StimulusHelper data attributes, values/targets/actions, and controller file placement. Use when adding JavaScript behavior to a Folio component, wiring data-controller / data-action / data-target, using StimulusHelper in Slim, or writing a new Stimulus controller in Folio or a host app.
| name | folio-slim |
| description | Slim template formatting and best practices for Folio components and views. Use when writing or editing .slim templates, reviewing Slim formatting, or when the user asks about Slim conventions, multi-line attributes, or template structure in Folio. |
Don't put logic in - lines. Extract a private component method and call it with =:
/ Bad
- classes = ["foo", ("bar" if @active)].compact.join(" ")
div class=classes
/ Good — move to a component method
div class=wrapper_class_name
When a plain view still needs several Ruby setup lines, prefer one ruby:
block over repeated - lines. In ViewComponent templates, move that setup to
private component methods whenever practical; in Rails views, a short ruby:
block is acceptable and clearer than multi-line - control flow.
When an element has multiple attributes, use bracket syntax without a space before [:
a[
class="f-c-ui-button"
class="f-c-ui-button--primary"
href=@url
data=stimulus_action(click: "onClick")
]
For a single short attribute, keep it inline:
a href="#section"
span.badge data-count=@count
If an attribute value becomes complex or multi-line, move it to a private component method so the template stays concise:
/ Bad
button data=stimulus_action({ click: "accept", keydown: "acceptFromKeyboard" },
{ text: suggestion.text, key: suggestion.key })
/ Good
button data=suggestion_data(suggestion)
Do not split a single Slim attribute value expression across lines. If an attribute value is too long or complex, extract it to a component method instead of wrapping the Ruby call inside the attribute.
class attributesUse separate class attributes instead of string concatenation or array joining:
/ Good
div[
class="f-c-ui-alert"
class="f-c-ui-alert--danger"
class=@class_name
]
/ Bad
div class="f-c-ui-alert f-c-ui-alert--danger #{@class_name}"
Slim merges multiple class attributes automatically. nil values are safely ignored.
Use .class-name shorthand on div (tag is implicit) and tag.class-name on other elements:
.f-c-ui-modal__body
span.f-c-ui-modal__label = @label
button.f-c-ui-modal__close type="button"
When an element already uses bracket syntax with multiple class attributes, don't mix .shorthand — use class attributes consistently:
/ Good — all classes as attributes
li[
class="nav-item"
class="f-c-ui-tabs__nav-item"
hidden=tab[:hidden]
]
/ Bad — mixing shorthand with class attributes
li.nav-item[
class="f-c-ui-tabs__nav-item"
hidden=tab[:hidden]
]
Pass the value directly — Slim omits the attribute when nil or false:
input disabled=@disabled
button hidden=@hidden
= for escaped Ruby output (default, safe)' at line start for a trailing space (e.g. between inline elements)== (unescaped output). Prefer = safe_join(...) or = tag.span(...) to build HTML safely:/ Bad — unescaped, risky
== [t(".line_one"), t(".line_two")].join("<br>")
/ Good — safe_join handles html_safe pieces
= safe_join([t(".line_one"), t(".line_two")], tag.br)
Use == only when rendering a trusted html_safe string where no safe alternative exists.
Prefer relative I18n keys starting with . in views and component templates.
Do not flag relative keys as issues; they are intentional and preferred.
If a template exceeds ~50 lines or has deeply nested conditionals, split into child ViewComponents or slots. The template should be mostly structure; logic belongs in component methods.
See folio-view-component skill for composition patterns.
Use Slim comments (/) which are stripped from output. Avoid HTML comments (/!) unless they must appear in the rendered page.
Use *method to build a tag from a hash (tag name, attributes) returned by a component method:
*tag
= @label
Where tag is a component method returning e.g. { tag: :a, href: @url, class: "btn" }.
slim-lint <path> on all Slim files (see AGENTS.md).
app/components/folio/console/ui/*_component.slim.skills/folio-view-component/SKILL.md