Surface.Code (SurfaceFormatter v0.2.0) View Source
Utilities for dealing with Surface code
Link to this section Summary
Functions
Formats the given Surface code string. (Typically the contents of an ~H
sigil or .sface
file.)
Link to this section Functions
Specs
format_string!(String.t(), [Surface.Code.Formatter.option()]) :: String.t()
Formats the given Surface code string. (Typically the contents of an ~H
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 three exceptions:
- Macro components (with names starting with
#
, such as<#Markdown>
) <pre>
tags<code>
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
If there is a not a lack of whitespace that needs to be respected, the
formatter puts separate nodes (e.g. HTML elements, interpolations {{ ... }}
,
etc) on their own line. This means that
<div> <p>Hello</p> {{1 + 1}} <p>Goodbye</p> </div>
will be formatted as
<div>
<p>Hello</p>
{{ 1 + 1 }}
<p>Goodbye</p>
</div>
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
<section>
Hello
</section>
will be formatted as
<section>
Hello
</section>
It also means that
<section>
<p>Hello</p>
<p>and</p>
<p>Goodbye</p>
</section>
will be formatted as
<section>
<p>Hello</p>
<p>and</p>
<p>Goodbye</p>
</section>
Attributes
HTML attributes such as class
in <p class="container">
are formatted to
make use of Surface features.
Inline literals
String, integer, and boolean literals are placed after the =
without any
interpolation brackets ({{ }}
). This means that
<Component foo={{ "hello" }} bar={{123}} secure={{ false }} />
will be formatted as
<Component foo="hello" bar=123 secure=false />
One exception is that 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]}}
becomeslist={{ [1, 2, 3] }}
things={{ %{one: "1", two: "2"}}}
becomesthings={{ %{ 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
/>
Note in the above example that if the Elixir code formatter introduces
newlines, whitespace between the expression and the interpolation brackets is
collapsed. That is to say the formatter will emit list={{[
instead of
list={{ [
.
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: [...],
# ...
]
HTML Comments
The formatter removes HTML comments. This is because the Surface parser (which SurfaceFormatter uses under the hood) does not expose them.
This means
<div>
<!-- Some comment -->
<p>Hello</p>
</div>
becomes
<div>
<p>Hello</p>
</div>
It is recommended to use an interpolated Elixir comment instead:
<div>
{{ # Some comment }}
<p>Hello</p>
</div>
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.