diff options
Diffstat (limited to 'docs/content/guide')
| -rw-r--r-- | docs/content/guide/components.md | 348 | ||||
| -rw-r--r-- | docs/content/guide/css_and_js.md | 230 | ||||
| -rw-r--r-- | docs/content/guide/index.md | 196 | ||||
| -rw-r--r-- | docs/content/guide/integrations.md | 3 | ||||
| -rw-r--r-- | docs/content/guide/motivation.md | 115 | ||||
| -rw-r--r-- | docs/content/guide/performance.md | 3 | ||||
| -rw-r--r-- | docs/content/guide/slots.md | 175 |
7 files changed, 1070 insertions, 0 deletions
diff --git a/docs/content/guide/components.md b/docs/content/guide/components.md new file mode 100644 index 0000000..ac8a77f --- /dev/null +++ b/docs/content/guide/components.md @@ -0,0 +1,348 @@ +--- +title: Components +description: Declaring and using components. +--- + +<Header title="Components"> +</Header> + +## Declaring and Using Components + +The components are simple text files that look like regular Jinja templates, with three requirements: + +**First**, components must be placed inside a folder registered in the catalog or a subfolder of it. + +```python +catalog.add_folder("myapp/components") +``` + +You can call that folder whatever you want, not just "components". You can also add more than one folder: + +```python +catalog.add_folder("myapp/layouts") +catalog.add_folder("myapp/components") +``` + +If you end up having more than one component with the same name, the one in the first folder will take priority. + +**Second**, they must have a ".jinja" extension. This also helps code editors automatically select the correct language syntax to highlight. However, you can configure it in the catalog. + +**Third**, the component name must start with an uppercase letter. Why? This is how JinjaX differentiates a component from a regular HTML tag when using it. I recommend using PascalCase names, like Python classes. + +The name of the file (minus the extension) is also how you call the component. For example, if the file is "components/PersonForm.jinja": + +``` +└ myapp/ + ├── app.py + ├── components/ + └─ PersonForm.jinja +``` + +The name of the component is "PersonForm" and can be called like this: + +From Python code or a non-component template: + +- `catalog.render("PersonForm")` + +From another component: + +- `<PersonForm> some content </PersonForm>`, or +- `<PersonForm />` + +If the component is in a subfolder, the name of that folder becomes part of its name too: + +``` +└ myapp/ + ├── app.py + ├── components/ + └─ person + └─ PersonForm.jinja +``` + +A "components/person/PersonForm.jinja" component is named "person.PersonForm", meaning the name of the subfolder and the name of the file separated by a dot. This is the full name you use to call it: + +From Python code or a non-component template: + +- `catalog.render("person.PersonForm")` + +From another component: + +- `<person.PersonForm> some content </person.PersonForm>`, or +- `<person.PersonForm />` + +Notice how the folder name doesn't need to start with an uppercase if you don't want it to. + +<a href="/static/img/anatomy-en.png" target="_blank"> + <img src="/static/img/anatomy-en.png" style="margin:0 auto;width:90%;max-width:35rem;"> +</a> + +## Taking Arguments + +More often than not, a component takes one or more arguments to render. Every argument must be declared at the beginning of the component with `{#def arg1, arg2, ... #}`. + +```html+jinja +{#def action, method="post", multipart=False #} + +<form method="{{ method }}" action="{{ action }}" + {%- if multipart %} enctype="multipart/form-data"{% endif %} +> + {{ content }} +</form> +``` + +In this example, the component takes three arguments: "action", "method", and "multipart". The last two have default values, so they are optional, but the first one doesn't. That means it must be passed a value when rendering the component. + +The syntax is exactly like how you declare the arguments of a Python function (in fact, it's parsed by the same code), so it can even include type comments, although they are not used by JinjaX (yet!). + +```python +{#def + data: dict[str, str], + method: str = "post", + multipart: bool = False +#} +... +``` + +## Passing Arguments + +There are two types of arguments: strings and expressions. + +### String + +Strings are passed like regular HTML attributes: + +```html+jinja +<Form action="/new" method="PATCH"> ... </Form> + +<Alert message="Profile updated" /> + +<Card title="Hello world" type="big"> ... </Card> +``` + +### Expressions + +There are two different but equivalent ways to pass non-string arguments: + +"Jinja-like", where you use double curly braces instead of quotes: + +```html+jinja title="Jinja-like" +<Example + columns={{ 2 }} + tabbed={{ False }} + panels={{ {'one': 'lorem', 'two': 'ipsum'} }} + class={{ 'bg-' + color }} +/> +``` + +... and "Vue-like", where you keep using quotes, but prefix the name of the attribute with a colon: + +```html+jinja title="Vue-like" +<Example + :columns="2" + :tabbed="False" + :panels="{'one': 'lorem', 'two': 'ipsum'}" + :class="'bg-' + color" +/> +``` + +<Callout type="note"> + For `True` values, you can just use the name, like in HTML: + <br> + ```html+jinja + <Example class="green" hidden /> + ``` +</Callout> + +<Callout type="note"> + You can also use dashes when passing an argument, but they will be translated to underscores: + <br> + ```html+jinja + <Example aria-label="Hi" /> + ``` + <br> + ```html+jinja title="Example.jinja" + {#def aria_label = "" #} + ... + ``` +</Callout> + +## With Content + +There is always an extra implicit argument: **the content** inside the component. Read more about it in the [next](/guide/slots) section. + +## Extra Arguments + +If you pass arguments not declared in a component, those are not discarded but rather collected in an `attrs` object. + +You then call `attrs.render()` to render the received arguments as HTML attributes. + +For example, this component: + +```html+jinja title="Card.jinja" +{#def title #} +<div {{ attrs.render() }}> + <h1>{{ title }}</h1> + {{ content }} +</div> +``` + +Called as: + +```html +<Card title="Products" class="mb-10" open>bla</Card> +``` + +Will be rendered as: + +```html +<div class="mb-10" open> + <h1>Products</h1> + bla +</div> +``` + +You can add or remove arguments before rendering them using the other methods of the `attrs` object. For example: + +```html+jinja +{#def title #} +{% do attrs.set(id="mycard") -%} + +<div {{ attrs.render() }}> + <h1>{{ title }}</h1> + {{ content }} +</div> +``` + +Or directly in the `attrs.render()` call: + +```html+jinja +{#def title #} + +<div {{ attrs.render(id="mycard") }}> + <h1>{{ title }}</h1> + {{ content }} +</div> +``` + +<Callout type="info"> +The string values passed into components as attrs are not cast to `str` until the string representation is **actually** needed, for example when `attrs.render()` is invoked. +</Callout> + +### `attrs` Methods + +#### `.render(name=value, ...)` + +Renders the attributes and properties as a string. + +Any arguments you use with this function are merged with the existing +attibutes/properties by the same rules as the `HTMLAttrs.set()` function: + +- Pass a name and a value to set an attribute (e.g. `type="text"`) +- Use `True` as a value to set a property (e.g. `disabled`) +- Use `False` to remove an attribute or property +- The existing attribute/property is overwritten **except** if it is `class`. + The new classes are appended to the old ones instead of replacing them. +- The underscores in the names will be translated automatically to dashes, + so `aria_selected` becomes the attribute `aria-selected`. + +To provide consistent output, the attributes and properties +are sorted by name and rendered like this: +`<sorted attributes> + <sorted properties>`. + +```html+jinja +<Example class="ipsum" width="42" data-good /> +``` +```html+jinja +<div {{ attrs.render() }}> +<!-- <div class="ipsum" width="42" data-good> --> + +<div {{ attrs.render(class="abc", data_good=False, tabindex=0) }}> +<!-- <div class="abc ipsum" width="42" tabindex="0"> --> +``` + +<Callout type="warning"> +Using `<Component {{ attrs.render() }}>` to pass the extra arguments to other components **WILL NOT WORK**. That is because the components are translated to macros before the page render. + +You must pass them as the special argument `_attrs`. + +```html+jinja +{#--- WRONG 😵 ---#} +<MyButton {{ attrs.render() }} /> + +{#--- GOOD 👍 ---#} +<MyButton _attrs={{ attrs }} /> +<MyButton :_attrs="attrs" /> +``` +</Callout> + +#### `.set(name=value, ...)` + +Sets an attribute or property + +- Pass a name and a value to set an attribute (e.g. `type="text"`) +- Use `True` as a value to set a property (e.g. `disabled`) +- Use `False` to remove an attribute or property +- If the attribute is "class", the new classes are appended to + the old ones (if not repeated) instead of replacing them. +- The underscores in the names will be translated automatically to dashes, + so `aria_selected` becomes the attribute `aria-selected`. + +```html+jinja title="Adding attributes/properties" +{% do attrs.set( + id="loremipsum", + disabled=True, + data_test="foobar", + class="m-2 p-4", +) %} +``` + +```html+jinja title="Removing attributes/properties" +{% do attrs.set( + title=False, + disabled=False, + data_test=False, + class=False, +) %} +``` + +#### `.setdefault(name=value, ...)` + +Adds an attribute, but only if it's not already present. + +The underscores in the names will be translated automatically to dashes, so `aria_selected` +becomes the attribute `aria-selected`. + +```html+jinja +{% do attrs.setdefault( + aria_label="Products" +) %} +``` + +#### `.add_class(name1, name2, ...)` + +Adds one or more classes to the list of classes, if not already present. + +```html+jinja +{% do attrs.add_class("hidden") %} +{% do attrs.add_class("active", "animated") %} +``` + +#### `.remove_class(name1, name2, ...)` + +Removes one or more classes from the list of classes. + +```html+jinja +{% do attrs.remove_class("hidden") %} +{% do attrs.remove_class("active", "animated") %} +``` + +#### `.get(name, default=None)` + +Returns the value of the attribute or property, +or the default value if it doesn't exist. + +```html+jinja +{%- set role = attrs.get("role", "tab") %} +``` + +...
\ No newline at end of file diff --git a/docs/content/guide/css_and_js.md b/docs/content/guide/css_and_js.md new file mode 100644 index 0000000..8e296e2 --- /dev/null +++ b/docs/content/guide/css_and_js.md @@ -0,0 +1,230 @@ +--- +title: Adding CSS and JS +description: Your components might need custom styles or custom JavaScript for many reasons. +--- + +<Header title="Adding CSS and JS"> +Your components might need custom styles or custom JavaScript for many reasons. +</Header> +Instead of using global stylesheet or script files, writing assets for each individual component has several advantages: + +- **Portability**: You can copy a component from one project to another, knowing it will keep working as expected. +- **Performance**: Only load the CSS and JS that you need on each page. Additionally, the browser will have already cached the assets of the components for other pages that use them. +- **Simple testing**: You can test the JS of a component independently from others. + +## Auto-loading assets + +JinjaX searches for `.css` and `.js` files with the same name as your component in the same folder and automatically adds them to the list of assets included on the page. For example, if your component is `components/common/Form.jinja`, both `components/common/Form.css` and `components/common/Form.js` will be added to the list, but only if those files exist. + +## Manually declaring assets + +In addition to auto-loading assets, the CSS and/or JS of a component can be declared in the metadata header with `{#css ... #}` and `{#js ... #}`. + +```html +{#css lorem.css, ipsum.css #} +{#js foo.js, bar.js #} +``` + +- The file paths must be relative to the root of your components catalog (e.g., `components/form.js`) or absolute (e.g., `http://example.com/styles.css`). +- Multiple assets must be separated by commas. +- Only **one** `{#css ... #}` and **one** `{#js ... #}` tag is allowed per component at most, but both are optional. + +### Global assets + +The best practice is to store both CSS and JS files of the component within the same folder. Doing this has several advantages, including easier component reuse in other projects, improved code readability, and simplified debugging. + +However, there are instances when you may need to rely on global CSS or JS files, such as third-party libraries. In such cases, you can specify these dependencies in the component's metadata using URLs that start with either "/", "http://," or "https://." + +When you do this, JinjaX will render them as is, instead of prepending them with the component's prefix like it normally does. + +For example, this code: + +```html+jinja +{#css foo.css, bar.css, /static/bootstrap.min.css #} +{#js http://example.com/cdn/moment.js, bar.js #} + +{{ catalog.render_assets() }} +``` + +will be rendered as this HTML output: + +```html +<link rel="stylesheet" href="/static/components/foo.css"> +<link rel="stylesheet" href="/static/components/bar.css"> +<link rel="stylesheet" href="/static/bootstrap.min.css"> +<script type="module" src="http://example.com/cdn/moment.js"></script> +<script type="module" src="/static/components/bar.js"></script> +``` + +## Including assets in your pages + +The catalog will collect all CSS and JS file paths from the components used on a "page" render on the `catalog.collected_css` and `catalog.collected_js` lists. + +For example, after rendering this component: + +```html+jinja title="components/MyPage.jinja" +{#css mypage.css #} +{#js mypage.js #} + +<Layout title="My page"> + <Card> + <CardBody> + <h1>Lizard</h1> + <p>The Iguana is a type of lizard</p> + </CardBody> + <CardActions> + <Button size="small">Share</Button> + </CardActions> + </Card> +</Layout> +``` + +Assuming the `Card` and `Button` components declare CSS assets, this will be the state of the `collected_css` list: + +```py +catalog.collected_css +['mypage.css', 'card.css', 'button.css'] +``` + +You can add the `<link>` and `<script>` tags to your page automatically by calling `catalog.render_assets()` like this: + +```html+jinja title="components/Layout.jinja" hl_lines="8" +{#def title #} + +<!DOCTYPE html> +<html lang="en"> +<head> + <meta charset="utf-8"> + <title>{{ title }}</title> + {{ catalog.render_assets() }} +</head> +<body> + {{ content }} +</body> +</html> +``` + +The variable will be rendered as: + +```html +<link rel="stylesheet" href="/static/components/mypage.css"> +<link rel="stylesheet" href="/static/components/card.css"> +<link rel="stylesheet" href="/static/components/button.css"> +<script type="module" src="/static/components/mypage.js"></script> +<script type="module" src="/static/components/card.js"></script> +<script type="module" src="/static/components/button.js"></script> +``` + +## Middleware + +The tags above will not work if your application can't return the content of those files. Currently, it can't. + +For that reason, JinjaX includes WSGI middleware that will process those URLs if you add it to your application. + +```py +from flask import Flask +from jinjax import Catalog + +app = Flask(__name__) + +# Here we add the Flask Jinja globals, filters, etc., like `url_for()` +catalog = jinjax.Catalog(jinja_env=app.jinja_env) + +catalog.add_folder("myapp/components") + +app.wsgi_app = catalog.get_middleware( + app.wsgi_app, + autorefresh=app.debug, +) +``` + +The middleware uses the battle-tested [Whitenoise library](http://whitenoise.evans.io/) and will only respond to the *.css* and *.js* files inside the component(s) folder(s). You can configure it to also return files with other extensions. For example: + +```python +catalog.get_middleware(app, allowed_ext=[".css", .js", .svg", ".png"]) +``` + +Be aware that if you use this option, `get_middleware()` must be called **after** all folders are added. + +## Good practices + +### CSS Scoping + +The styles of your components will not be auto-scoped. This means the styles of a component can affect other components and likewise, it will be affected by global styles or the styles of other components. + +To protect yourself against that, *always* add a custom class to the root element(s) of your component and use it to scope the rest of the component styles. + +You can even use this syntax now supported by [all modern web browsers](https://caniuse.com/css-nesting): + +```sass +.Parent { + .foo { ... } + .bar { ... } +} +``` + +The code above will be interpreted as + +```css +.Parent .foo { ... } +.Parent .bar { ... } +``` + +Example: + +```html+jinja title="components/Card.jinja" +{#css card.css #} + +<div {{ attrs.render(class="Card") }}> + <h1>My Card</h1> + ... +</div> +``` + +```sass title="components/card.css" +/* 🚫 DO NOT do this */ +h1 { font-size: 2em; } +h2 { font-size: 1.5em; } +a { color: blue; } + +/* 👍 DO THIS instead */ +.Card { + & h1 { font-size: 2em; } + & h2 { font-size: 1.5em; } + & a { color: blue; } +} + +/* 👍 Or this */ +.Card h1 { font-size: 2em; } +.Card h2 { font-size: 1.5em; } +.Card a { color: blue; } +``` + +<Callout type="warning"> +Always use a class **instead of** an `id`, or the component will not be usable more than once per page. +</Callout> + +### JS events + +Your components might be inserted in the page on-the-fly, after the JavaScript files have been loaded and executed. So, attaching events to the elements on the page on load will not be enough: + +```js title="components/card.js" +// This will fail for any Card component inserted after page load +document.querySelectorAll('.Card button.share') + .forEach((node) => { + node.addEventListener("click", handleClick) + }) + +/* ... etc ... */ +``` + +A solution can be using event delegation: + +```js title="components/card.js" +// This will work for any Card component inserted after page load +document.addEventListener("click", (event) => { + if (event.target.matches(".Card button.share")) { + handleClick(event) + } +}) +``` diff --git a/docs/content/guide/index.md b/docs/content/guide/index.md new file mode 100644 index 0000000..0c092ea --- /dev/null +++ b/docs/content/guide/index.md @@ -0,0 +1,196 @@ +--- +title: Introduction +--- + +<Header title="Introduction"> +JinjaX is a Python library for creating reusable "components": encapsulated template snippets that can take arguments and render to HTML. They are similar to React or Vue components, but they render on the server side, not in the browser. +</Header> + +Unlike Jinja's `{% include "..." %}` or macros, JinjaX components integrate naturally with the rest of your template code. + +```html+jinja +<div> + <Card class="bg-gray"> + <h1>Products</h1> + {% for product in products %} + <Product product={{ product }} /> + {% endfor %} + </Card> +</div> +``` + +## Features + +### Simple + +JinjaX components are simple Jinja templates. You use them as if they were HTML tags without having to import them: easy to use and easy to read. + +### Encapsulated + +They are independent of each other and can link to their own CSS and JS, so you can freely copy and paste components between applications. + +### Testable + +All components can be unit tested independently of the pages where they are used. + +### Composable + +A JinjaX component can wrap HTML code or other components with a natural syntax, as if they were another tag. + +### Modern + +They are a great complement to technologies like [TailwindCSS](https://tailwindcss.com/), [htmx](https://htmx.org/), or [Hotwire](https://hotwired.dev/). + +## Usage + +#### Install + +Install the library using `pip`. + +```bash +pip install jinjax +``` + +#### Components folder + +Then, create a folder that will contain your components, for example: + +``` +└ myapp/ + ├── app.py + ├── components/ 🆕 + │ └── Card.jinja 🆕 + ├── static/ + ├── templates/ + └── views/ +└─ requirements.txt +``` + +#### Catalog + +Finally, you must create a "catalog" of components in your app. This is the object that manages the components and their global settings. You then add the path of the folder with your components to the catalog: + +```python +from jinjax import Catalog + +catalog = Catalog() +catalog.add_folder("myapp/components") +``` + +#### Render + +You will use the catalog to render components from your views. + +```python +def myview(): + ... + return catalog.render( + "Page", + title="Lorem ipsum", + message="Hello", + ) +``` + +In this example, it is a component for the whole page, but you can also render smaller components, even from inside a regular Jinja template if you add the catalog as a global: + +```python +app.jinja_env.globals["catalog"] = catalog +``` + +```html+jinja +{% block content %} +<div> + {{ catalog.irender("LikeButton", title="Like and subscribe!", post=post) }} +</div> +<p>Lorem ipsum</p> +{{ catalog.irender("CommentForm", post=post) }} +{% endblock %} +``` + +## How It Works + +JinjaX uses Jinja to render the component templates. In fact, it currently works as a pre-processor, replacing all: + +```html +<Component attr="value">content</Component> +``` + +with function calls like: + +```html+jinja +{% call catalog.irender("Component", attr="value") %}content{% endcall %} +``` + +These calls are evaluated at render time. Each call loads the source of the component file, parses it to extract the names of CSS/JS files, required and/or optional attributes, pre-processes the template (replacing components with function calls, as before), and finally renders the new template. + +### Reusing Jinja's Globals, Filters, and Tests + +You can add your own global variables and functions, filters, tests, and Jinja extensions when creating the catalog: + +```python +from jinjax import Catalog + +catalog = Catalog( + globals={ ... }, + filters={ ... }, + tests={ ... }, + extensions=[ ... ], +) +``` + +or afterward. + +```python +catalog.jinja_env.globals.update({ ... }) +catalog.jinja_env.filters.update({ ... }) +catalog.jinja_env.tests.update({ ... }) +catalog.jinja_env.extensions.extend([ ... ]) +``` + +The ["do" extension](https://jinja.palletsprojects.com/en/3.0.x/extensions/#expression-statement) is enabled by default, so you can write things like: + +```html+jinja +{% do attrs.set(class="btn", disabled=True) %} +``` + +### Reusing an Existing Jinja Environment + +You can also reuse an existing Jinja Environment, for example: + +#### Flask: + +```python +app = Flask(__name__) + +# Here we add the Flask Jinja globals, filters, etc., like `url_for()` +catalog = jinjax.Catalog(jinja_env=app.jinja_env) +``` + +#### Django: + +First, configure Jinja in `settings.py` and [jinja_env.py](https://docs.djangoproject.com/en/5.0/topics/templates/#django.template.backends.jinja2.Jinja2). + +To have a separate "components" folder for shared components and also have "components" subfolders at each Django app level: + +```python +import jinjax +from jinja2.loaders import FileSystemLoader + +def environment(loader: FileSystemLoader, **options): + env = Environment(loader=loader, **options) + + ... + + env.add_extension(jinjax.JinjaX) + catalog = jinjax.Catalog(jinja_env=env) + + catalog.add_folder("components") + for dir in loader.searchpath: + catalog.add_folder(os.path.join(dir, "components")) + + return env +``` + +#### FastAPI: + +TBD
\ No newline at end of file diff --git a/docs/content/guide/integrations.md b/docs/content/guide/integrations.md new file mode 100644 index 0000000..0884d22 --- /dev/null +++ b/docs/content/guide/integrations.md @@ -0,0 +1,3 @@ +--- +title: Integrations +---
\ No newline at end of file diff --git a/docs/content/guide/motivation.md b/docs/content/guide/motivation.md new file mode 100644 index 0000000..90602b5 --- /dev/null +++ b/docs/content/guide/motivation.md @@ -0,0 +1,115 @@ +--- +title: Motivation +--- +<Header title="Motivation"> +An overview of what Jinja is about, and a glimpse into my disjointed decision-making process that got me here. +</Header> + +## Components are cool + +Despite the complexity of a single-page application, some programmers claim React or Vue offer a better development experience than traditional server-side rendered templates. I believe this is mostly because of the greatest improvement React introduced to web development: components. + +<small> +Components, *as a way to organize template code*. Reactivity is cool too, but unrelated to the main issue. +</small> + +When writing Python, we aim for the code to be easy to understand and test. However, we often forget all of that when writing templates that don't even meet basic standards: long methods, deep conditional nesting, and mysterious variables everywhere. + +Components are way cooler than the HTML soup tag of server-side rendered templates. They make it very clear what arguments they take and how they can render. More than anything, components are modular: markup, logic, and relevant styles all in one package. You can copy and paste them between projects, and you can share them with other people. + +This means a community has formed around sharing these components. Now you can easily find hundreds of ready-to-use components—some of them very polished—for every common UI widget, even the "complex" ones, like color-pickers. The big problem is that you can only use them with React (and Vue components with Vue, etc.) and in a single-page application. + +Jinja is about bringing that innovation back to server-side-rendered applications. + +## Not quite there: Jinja macros + +An underestimated feature of Jinja is *macros*. Jinja [macros](https://jinja.palletsprojects.com/en/3.0.x/templates/#macros) are template snippets that work like functions: They can have positional or keyword arguments, and when called return the rendered text inside. + +```html+jinja +{% macro input(name, value="", type="text", size=20) -%} + <input type="{{ type }}" name="{{ name }}" + value="{{ value|e }}" size="{{ size }}"> +{%- endmacro %} + +{% macro button(type="button") -%} + <button type="{{ type }}" class="btn-blue"> + {{ caller() }} + </button> +{%- endmacro %} +``` + +You can then import the macro to your template to use it: + +```html+jinja +{% from 'forms.html' import input, button %} + +<p>{{ input("username") }}</p> +<p>{{ input("password", type="password") }}</p> +{% call button("submit") %}Submit{% endcall %} +``` +You must use the `{% call x %}` to pass the child content to the macro—by using the weird incantation `{{ caller() }}`—otherwise you can just call it like it were a function. + +So, can we use macros as components and call it a day? Well... no. This looks terrible: + +```html+jinja +{% call Card(label="Hello") %} + {% call MyButton(color="blue", shadowSize=2) %} + {{ Icon(name="ok") }} Click Me + {% endcall %} +{% endcall %} +``` + +compared to how you would write it with JSX: + +```html +<Card label="Hello"> + <MyButton color="blue" shadowSize={2}> + <Icon name="ok" /> Click Me + </MyButton> +</Card> +``` + +But macros are *almost* there. They would be a great foundation if we could adjust the syntax just a little. + +## Strong alternative: Mako + +At some point, I considered dropping this idea and switching to [Mako](https://www.makotemplates.org/), a template library by Michael Bayer (of SQLAlchemy fame). + +It's a hidden gem that doesn't get much attention because of network effects. See how close you can get with it: + +```html+mako +<%def name="layout()"> # <--- A "macro" + <div class="mainlayout"> + <div class="header"> + ${caller.header()} + </div> + + <div class="sidebar"> + ${caller.sidebar()} + </div> + + <div class="content"> + ${caller.body()} + </div> + </div> +</%def> + +## calls the layout def <--- Look! Python-style comments + +<%self:layout> + <%def name="header()"> # <--- This is like a "slot"! + I am the header + </%def> + <%def name="sidebar()"> + <ul> + <li>sidebar 1</li> + <li>sidebar 2</li> + </ul> + </%def> + this is the body +</%self:layout> +``` + +Mako also has `<% include %>`s with arguments, which is another way of doing components if you don't need to pass content. + +However, in the end, the network effects, my familiarity with Jinja, and a little of not-invented-here syndrome tipped the scales to write a Jinja extension. diff --git a/docs/content/guide/performance.md b/docs/content/guide/performance.md new file mode 100644 index 0000000..609b952 --- /dev/null +++ b/docs/content/guide/performance.md @@ -0,0 +1,3 @@ +--- +title: Performance +--- diff --git a/docs/content/guide/slots.md b/docs/content/guide/slots.md new file mode 100644 index 0000000..991f327 --- /dev/null +++ b/docs/content/guide/slots.md @@ -0,0 +1,175 @@ +--- +title: Slots / Content +description: Working with content in components. +--- + +<Header title="Slots / Content"> +Besides attributes, components can also accept content to render inside them. +</Header> + +Everything between the open and close tags of the components will be rendered and passed to the component as an implicit `content` variable + +This is a very common pattern, and it is called a **_slot_**. A slot is a placeholder for content that can be provided by the user of the component. For example, we may have a `<FancyButton>` component that supports usage like this: + +```html+jinja +<FancyButton> + <i class="icon></i> Click me! +</FancyButton> +``` + +The template of `<FancyButton>` looks like this: + +```html+jinja +<button class="fancy-btn"> + {{ content }} +</button> +``` + + + +The `<FancyButton>` is responsible for rendering the outer `<button>` (and its fancy styling), while the inner content is provided by the parent component. + +A great use case of the `content` is to make layout components: + +<ExampleTabs + prefix="slots-layouts" + panels={{ { + "ArchivePage.jinja": "guide.slots.CompArchive", + "Layout.jinja": "guide.slots.CompLayout", + } }} +/> + + +## Fallback Content + +There are cases when it's useful to specify fallback (i.e. default) content for a slot, to be rendered only when no content is provided. For example, in a `<SubmitButton>` component: + +```html+jinja +<button type="submit"> + {{ content }} +</button> +``` + +We might want the text "Submit" to be rendered inside the `<button>` if the parent didn't provide any slot content. The special "content" variable is just a string like any other, so we can test if it's empty to make "Submit" the fallback content: + +```html+jinja +<button type="submit"> + {% if content %} + {{ content }} + {% else %} + Submit <!-- fallback content --> + {% endif %} +</button> +``` + +Now when we use `<SubmitButton>` in a parent component, providing no content for the slot: + +```html+jinja +<SubmitButton /> +``` + +<Callout type="info"> +The `content` of a self-closing component is an empty string. +</Callout> + +This will render the fallback content, "Submit": + +```html +<button type="submit">Submit</button> +``` + +But if we provide content: + +```html+jinja +<SubmitButton>Save</SubmitButton> +``` + +Then the provided content will be rendered instead: + +```html +<button type="submit">Save</button> +``` + + +## Multiple content slots (a.k.a. "named slots") + +There are cases when a component is complex enough to need multiple content slots. For example, a `<Modal>` component might need a `header`, a `body`, and a `footer` content. + +One way to implement it is using multiple content slots. To do so, instead of rendering `content` as a string, you can also _call_ it with name. Then, the parent component can provide a content _for_ that name. + + + +Note the `_slot` special variable. This is automatically available in the content in the parent component and contains the named the component has used to call request its content. + +The `_slot` variable is scoped to the content of that component, so it's not available outside of it: + +```html+jinja hl_lines="2 7 11" +<FancyButton> + {% if _slot == "hi" %} {# <--- _slot #} + Hello{% endif %} +</FancyButton> + +<FancyButton2> + {% if _slot == "hi" %} {# <--- This _slot is a different one #} + Sup?{% endif %} +</FancyButton2> + +{{ _slot }} {# <--- Undefined variable #} +``` + + +## Composability: better than named slots + +Named slots are a quick way to have multiple content slots, but are a bit messy beyond some simple cases. + +Composability offers a more flexible and idiomatic approach when multiple content slots are needed. The idea is to have separated components for each content slot, and then compose them together. Let's explore this concept using the same example as above. + +Consider a `Modal` component that requires three distinct sections: a header, a body, and a footer. Instead of using named slots, we can create separate components for each section and composing them within a `Modal` component wrapper. + +```html+jinja +<Modal> + + <ModalHeader> + <i class="icon-rocket"></i> + Hello World! + </ModalHeader> + + <ModalBody> + <p>The modal body.</p> + </ModalBody> + + <ModalFooter> + <button>Cancel</button> + <button>Save</button> + </ModalFooter> + +</Modal> +``` + +Now, the `Modal` component is responsible for rendering the outer `<dialog>` and its styling, while the inner content is provided by the child components. + +<ExampleTabs + prefix="slots-modal" + panels={{ { + "Modal.jinja": "guide.slots.Modal", + "ModalHeader.jinja": "guide.slots.ModalHeader", + "ModalBody.jinja": "guide.slots.ModalBody", + "ModalFooter.jinja": "guide.slots.ModalFooter", + } }} +/> + +### Advantages of Composability + +- **Flexibility**: You can easily rearrange, omit, or add new sections without modifying the core `Modal` component. +- **Reusability**: Each section (`ModalHeader`, `ModalBody`, `ModalFooter`) can be used independently or within other components. +- **Maintainability**: It's easier to update or style individual sections without affecting the others. + + +## Testing components with content + +To test a component in isolation, you can manually send a content argument using the special `_content` argument: + +```python +catalog.render("PageLayout", title="Hello world", _content="TEST") +``` + |