Specs

format_string!(String.t(), [option()]) :: String.t()

Formats the given Surface code string. (Typically the contents of an ~F sigil or .sface file.)

In short:

• HTML/Surface elements are indented to the right of their parents.
• Attributes are split on multiple lines if the line is too long; otherwise on the same line.
• Elixir code snippets (inside { }) are ran through the Elixir code formatter.
• Lack of whitespace is preserved, so that intended behaviors are not removed. (For example, <span>Foo bar baz</span> will not have newlines or spaces added.)

Below the Options section is a non-exhaustive list of behaviors of the formatter.

Options

• :line_length - the line length to aim for when formatting the document. Defaults to 98. As with the Elixir formatter, this value is used as reference but is not always enforced depending on the context.

Indentation

The formatter ensures that children are indented one tab (two spaces) in from their parent.

Whitespace

Whitespace that exists

As in regular HTML, any string of continuous whitespace is considered equivalent to any other string of continuous whitespace. There are four exceptions:

1. Macro components (with names starting with #, such as <#Markdown>)
2. <pre> tags
3. <code> tags
4. <script> tags

The contents of those tags are considered whitespace-sensitive, and developers should sanity check after running the formatter.

Whitespace that doesn't exist (Lack of whitespace)

As is sometimes the case in HTML, lack of whitespace is considered significant. Instead of attempting to determine which contexts matter, the formatter consistently retains lack of whitespace. This means that the following

<div><p>Hello</p></div>

will not be changed. However, the following

<div> <p> Hello </p> </div>

will be formatted as

<div>
  <p>
    Hello
  </p>
</div>

because of the whitespace on either side of each tag.

To be clear, this example

<div> <p>Hello</p> </div>

will be formatted as

<div>
  <p>Hello</p>
</div>

because of the lack of whitespace in between the opening and closing <p> tags and their child content.

Splitting children onto separate lines

In certain scenarios, the formatter will move nodes to their own line:

(Below, "element" means an HTML element or a Surface component.)

1. If an element contains other elements as children, it will be surrounded by newlines.
2. If there is a space after an opening tag or before a closing tag, it is converted to a newline.
3. If a closing tag is put on its own line, the formatter ensures there's a newline before the next sibling node.

Since SurfaceFormatter doesn't know if a component represents an inline or block element, it does not currently make distinctions between elements that should or should not be moved onto their own lines, other than the above rules.

This allows inline elements to be placed among text without splitting them onto their own lines:

The <b>Dialog</b> is a stateless component. All event handlers
had to be defined in the parent <b>LiveView</b>.

Newline characters

The formatter will not add extra newlines unprompted beyond moving nodes onto their own line. However, if the input code has extra newlines, the formatter will retain them but will collapse more than one extra newline into a single one.

This means that

<p>Hello</p>





<p>Goodbye</p>

will be formatted as

<p>Hello</p>

<p>Goodbye</p>

HTML attributes and component props

HTML attributes such as class in <p class="container"> and component props such as name in <Person name="Samantha"> are formatted to make use of Surface features.

Inline literals

String literals are placed after the = without any interpolation brackets ({ }). This means that

<Component foo={"hello"} />

will be formatted as

<Component foo="hello" />

Also, true boolean literals are formatted using the Surface shorthand whereby you can simply write the name of the attribute and it is passed in as true. For example,

<Component secure={true} />

and

<Component secure=true />

will both be formatted as

<Component secure />

Interpolation ({ } brackets)

Attributes that interpolate Elixir code with { } brackets are ran through the Elixir code formatter.

This means that:

• <Foo num={123456} /> becomes <Foo num={123_456} />
• list={[1,2,3]} becomes list={[1, 2, 3]}
• things={%{ one: "1", two: "2"}} becomes things={%{one: "1", two: "2"}}

Sometimes the Elixir code formatter will add line breaks in the formatted expression. In that case, SurfaceFormatter will ensure indentation lines up. If there is a single attribute, it will keep the attribute on the same line as the tag name, for example:

<Component list={[
  {"foo", foo},
  {"bar", bar}
]} />

However, if there are multiple attributes it will put them on separate lines:

<Child
  list={[
    {"foo", foo},
    {"bar", bar}
  ]}
  int={123}
/>

Whitespace in string attributes

Code semantics must be maintained

It's critical that a code formatter never change the semantics of the code it modifies. In other words, the behavior of a program should never change due to a code formatter.

The Whitespace section above outlines how SurfaceFormatter preserves code semantics by refusing to modify contents of <script>, <code> and <pre> tags as well as macro components. And for the same reason, the formatter does not introduce whitespace between HTML tags when there is none.

Code semantics in string attributes

This principle is also relevant to string attributes, such as:

<MyComponent string_prop="  string  with  whitespace  " />

SurfaceFormatter cannot reliably guess whether application behavior will be changed by formatting the contents of a string. For example, consider a component with the following interface:

<List items="
apples (fuji)
oranges (navel)
bell peppers (green)
" />

The component internally splits on newline characters and outputs the following HTML:

<ul>
  <li>apples (fuji)</li>
  <li>oranges (navel)</li>
  <li>bell peppers (green)</li>
</ul>

If SurfaceFormatter assumes it is safe to modify whitespace in string attributes, then the Surface code would likely change to this:

<List items="apples (fuji) oranges (navel) bell peppers (green)" />

Which would output the following HTML:

<ul>
  <li>apples (fuji) oranges (navel) bell peppers (green)</li>
</ul>

Notice that the behavior of the application would have changed simply by running the formatter. It is for this reason that SurfaceFormatter always retains precisely the same whitespace in attribute strings, including both space and newline characters.

Wrapping attributes on separate lines

In the Interpolation ({ } brackets) section we noted that attributes will each be put on their own line if there is more than one attribute and at least one contains a newline after being formatted by the Elixir code formatter.

There is another scenario where attributes will each be given their own line: any time the opening tag would exceed line_length if put on one line. This value is provided in .formatter.exs and defaults to 98.

The formatter indents attributes one tab in from the start of the opening tag for readability:

<div
  class="very long class value that causes this to exceed the established line length"
  aria-role="button"
>

If you desire to have a separate line length for mix format and mix surface.format, provide surface_line_length in .formatter.exs and it will be given precedence when running mix surface.format. For example:

# .formatter.exs

[
  surface_line_length: 120,
  import_deps: [...],
  # ...
]

Developer Responsibility

As with all changes (for both mix format and mix surface.format) it's recommended that developers don't blindly run the formatter on an entire codebase and commit, but instead sanity check each file to ensure the results are desired.

Specs

is_element?(surface_node()) :: boolean()

Returns true if the argument is an element (HTML element or surface component), false otherwise.

Specs

render_contents_verbatim?(tag()) :: boolean()

Given a tag, return whether to render the contens verbatim instead of formatting them. Specifically, don't modify contents of macro components or <pre> and <code> tags.