ui/docs/building-components.md
Components can range from small, highly reusable "atoms" to large units with lots of business logic specific to one workflow or action. In any scenario, these are things to keep in mind while developing components for the Vault UI.
Please note that these guidelines are aspirational and you will see instances of anti-patterns in the codebase. Many of these should be updated as we move forward. As with any rule set, sometimes it is appropriate to break the rule.
Route templates should render a Page component, which includes breadcrumbs, page title, and then renders whatever else should be on the page (often another scoped component).
<Page::CreateFoo /> and you can create it like ember g component page/create-foo -gc.<Page::CreateFoo @config={{this.model.config}} @foo={{this.model.foo}} />
Generally, we want the burden of deciding whether a component should render to live in the parent rather than the child.
{{#if}} block is on the parent.| 💡 Tips for reusability | Example |
|---|---|
| ✅ Add splattributes to the top level | <pre><div ...attributes> Something! </div></pre> |
| ✅ Pass a class or helper that controls a style | <pre><Block @title="Example" class="padding-0" /></pre> |
| ❌ Don't pass a new arg that controls a style | <pre><Block @title="Example" @hasPadding={{false}} /> </pre> |
| ✅ Minimize args passed, pass one arg that is rendered if present | <pre><Block @title="Example" @icon="key" /></pre> |
| ❌ Don't pass separate args required for icon to render | <pre><Block @title="Example" @hasIcon={{true}} @iconName="key" /> </pre> |