Skip to content

Commit c5ca81e

Browse files
parloughparlough
authored
Migrate from include to render where possible (#5770)
Contributes to #5768 Some includes rely on inheriting the parent still, which `render` purposefully doesn't support. They will need further updates before being able to migrate. Some rely on global data (such as `site.` variables), which 11ty doesn't yet expose to `render`, but likely will in the future. For now, those can keep using `include`.
1 parent f7cb68c commit c5ca81e

36 files changed

+105
-105
lines changed

‎src/_includes/head.html

+1-1
Original file line numberDiff line numberDiff line change
@@ -97,5 +97,5 @@
9797
{% endfor -%}
9898
{% endif -%}
9999

100-
{% include 'analytics.html' -%}
100+
{% render 'analytics.html' -%}
101101
</head>

‎src/_includes/page-header.html

+1-1
Original file line numberDiff line numberDiff line change
@@ -10,4 +10,4 @@ <h4 class="text-center">
1010
{% endif -%}
1111
{% endif -%}
1212
</header>
13-
{% if site.show_banner -%} {% include 'banner.html' %} {%- endif -%}
13+
{% if site.show_banner -%} {% render 'banner.html' %} {%- endif -%}

‎src/_layouts/default.html

+3-3
Original file line numberDiff line numberDiff line change
@@ -8,8 +8,8 @@
88
{% endif -%}
99
{% endif -%}
1010
<body class="{{layout}}{% if toc %}{% if toc == false %} hide_toc{% endif %}{% endif %}{% if obsolete %}{% if obsolete == true %} obsolete{% endif %}{% endif %}{% if site.show_banner == true %} show_banner{% endif %}{% if body_class %} {{ body_class }}{% endif %}">
11-
{% include 'cookie-notice.html' %}
12-
{% include 'gtags.html' %}
11+
{% render 'cookie-notice.html' %}
12+
{% render 'gtags.html' %}
1313
{% include 'page-header.html', obsolete:obsolete %}
1414
{% include 'navigation-side.html' %}
1515
<main id="page-content">
@@ -38,6 +38,6 @@ <h1>{{title }}</h1>
3838
</div>
3939
</article>
4040
</main>
41-
{% include 'page-footer.html' %}
41+
{% render 'page-footer.html' %}
4242
</body>
4343
</html>

‎src/_layouts/error.html

+3-3
Original file line numberDiff line numberDiff line change
@@ -2,15 +2,15 @@
22
<html lang="en">
33
{% include 'head.html' %}
44
<body class="{{layout}} hide_toc">
5-
{% include 'cookie-notice.html' %}
6-
{% include 'gtags.html' %}
5+
{% render 'cookie-notice.html' %}
6+
{% render 'gtags.html' %}
77
{% include 'page-header.html' %}
88
{% include 'navigation-side.html' %}
99
<main id="page-content">
1010
<div class="content">
1111
{{content}}
1212
</div>
1313
</main>
14-
{% include 'page-footer.html' %}
14+
{% render 'page-footer.html' %}
1515
</body>
1616
</html>

‎src/_layouts/homepage.html

+3-3
Original file line numberDiff line numberDiff line change
@@ -2,13 +2,13 @@
22
<html lang="en">
33
{% include 'head.html' %}
44
<body class="homepage">
5-
{% include 'cookie-notice.html' %}
6-
{% include 'gtags.html' %}
5+
{% render 'cookie-notice.html' %}
6+
{% render 'gtags.html' %}
77
{% include 'page-header.html' %}
88
{% include 'navigation-side.html' %}
99
<main id="page-content">
1010
{{content}}
1111
</main>
12-
{% include 'page-footer.html' %}
12+
{% render 'page-footer.html' %}
1313
</body>
1414
</html>

‎src/content/codelabs/async-await.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ Estimated time to complete this codelab: 40-60 minutes.
2828

2929
:::note
3030
This page uses embedded DartPads to display examples and exercises.
31-
{% include 'dartpads-embedded-troubleshooting.md' %}
31+
{% render 'dartpads-embedded-troubleshooting.md' %}
3232
:::
3333

3434
The exercises in this codelab have partially completed code snippets.

‎src/content/codelabs/dart-cheatsheet.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -22,7 +22,7 @@ for an explanation and the answer.
2222

2323
:::note
2424
This page uses embedded DartPads to display runnable examples.
25-
{% include 'dartpads-embedded-troubleshooting.md' %}
25+
{% render 'dartpads-embedded-troubleshooting.md' %}
2626
:::
2727

2828
## String interpolation

‎src/content/codelabs/iterables.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ Estimated time to complete this codelab: 60 minutes.
3333

3434
:::note
3535
This page uses embedded DartPads to display examples and exercises.
36-
{% include 'dartpads-embedded-troubleshooting.md' %}
36+
{% render 'dartpads-embedded-troubleshooting.md' %}
3737
:::
3838

3939
The exercises in this codelab have partially completed code snippets.

‎src/content/effective-dart/design.md

+22-22
Original file line numberDiff line numberDiff line change
@@ -340,7 +340,7 @@ previous guidelines state, either:
340340

341341
### PREFER naming a method `to___()` if it copies the object's state to a new object
342342

343-
{% include 'linter-rule-mention.md', rules:'use_to_and_as_if_applicable' %}
343+
{% render 'linter-rule-mention.md', rules:'use_to_and_as_if_applicable' %}
344344

345345
A *conversion* method is one that returns a new object containing a copy of
346346
almost all of the state of the receiver but usually in some different form or
@@ -358,7 +358,7 @@ dateTime.toLocal();
358358

359359
### PREFER naming a method `as___()` if it returns a different representation backed by the original object
360360

361-
{% include 'linter-rule-mention.md', rules:'use_to_and_as_if_applicable' %}
361+
{% render 'linter-rule-mention.md', rules:'use_to_and_as_if_applicable' %}
362362

363363
Conversion methods are "snapshots". The resulting object has its own copy of the
364364
original object's state. There are other conversion-like methods that return
@@ -520,7 +520,7 @@ you can in a procedural or functional language.
520520

521521
### AVOID defining a one-member abstract class when a simple function will do
522522

523-
{% include 'linter-rule-mention.md', rules:'one_member_abstracts' %}
523+
{% render 'linter-rule-mention.md', rules:'one_member_abstracts' %}
524524

525525
Unlike Java, Dart has first-class functions, closures, and a nice light syntax
526526
for using them. If all you need is something like a callback, just use a
@@ -543,7 +543,7 @@ abstract class Predicate<E> {
543543

544544
### AVOID defining a class that contains only static members
545545

546-
{% include 'linter-rule-mention.md', rules:'avoid_classes_with_only_static_members' %}
546+
{% render 'linter-rule-mention.md', rules:'avoid_classes_with_only_static_members' %}
547547

548548
In Java and C#, every definition *must* be inside a class, so it's common to see
549549
"classes" that exist only as a place to stuff static members. Other classes are
@@ -656,7 +656,7 @@ comment.
656656
<a id="avoid-mixing-in-a-class-that-isnt-intended-to-be-a-mixin"></a>
657657
### PREFER defining a pure `mixin` or pure `class` to a `mixin class`
658658

659-
{% include 'linter-rule-mention.md', rules:'prefer_mixin' %}
659+
{% render 'linter-rule-mention.md', rules:'prefer_mixin' %}
660660

661661
Dart previously (language version [2.12](/guides/language/evolution#dart-2-12)
662662
to [2.19](/guides/language/evolution#dart-2-19)) allowed any class that
@@ -708,7 +708,7 @@ A member belongs to an object and can be either methods or instance variables.
708708

709709
### PREFER making fields and top-level variables `final`
710710

711-
{% include 'linter-rule-mention.md', rules:'prefer_final_fields' %}
711+
{% render 'linter-rule-mention.md', rules:'prefer_final_fields' %}
712712

713713
State that is not *mutable*—that does not change over time—is
714714
easier for programmers to reason about. Classes and libraries that minimize the
@@ -821,7 +821,7 @@ dataSet.minimumValue;
821821

822822
### DO use setters for operations that conceptually change properties
823823

824-
{% include 'linter-rule-mention.md', rules:'use_setters_to_change_properties' %}
824+
{% render 'linter-rule-mention.md', rules:'use_setters_to_change_properties' %}
825825

826826
Deciding between a setter versus a method is similar to deciding between a
827827
getter versus a method. In both cases, the operation should be "field-like".
@@ -847,7 +847,7 @@ button.visible = false;
847847

848848
### DON'T define a setter without a corresponding getter
849849

850-
{% include 'linter-rule-mention.md', rules:'avoid_setters_without_getters' %}
850+
{% render 'linter-rule-mention.md', rules:'avoid_setters_without_getters' %}
851851

852852
Users think of getters and setters as visible properties of an object. A
853853
"dropbox" property that can be written to but not seen is confusing and
@@ -925,7 +925,7 @@ empty container, it might make sense to use a nullable type.
925925

926926
### AVOID returning `this` from methods just to enable a fluent interface
927927

928-
{% include 'linter-rule-mention.md', rules:'avoid_returning_this' %}
928+
{% render 'linter-rule-mention.md', rules:'avoid_returning_this' %}
929929

930930
Method cascades are a better solution for chaining method calls.
931931

@@ -1049,7 +1049,7 @@ various cases, but the rough summary is:
10491049

10501050
### DO type annotate variables without initializers
10511051

1052-
{% include 'linter-rule-mention.md', rules:'prefer_typing_uninitialized_variables' %}
1052+
{% render 'linter-rule-mention.md', rules:'prefer_typing_uninitialized_variables' %}
10531053

10541054
The type of a variable—top-level, local, static field, or instance
10551055
field—can often be inferred from its initializer. However, if there is no
@@ -1078,7 +1078,7 @@ if (node is Constructor) {
10781078

10791079
### DO type annotate fields and top-level variables if the type isn't obvious
10801080

1081-
{% include 'linter-rule-mention.md', rules:'type_annotate_public_apis' %}
1081+
{% render 'linter-rule-mention.md', rules:'type_annotate_public_apis' %}
10821082

10831083
Type annotations are important documentation for how a library should be used.
10841084
They form boundaries between regions of a program to isolate the source of a
@@ -1130,7 +1130,7 @@ annotations on APIs help *users* of your code, types on private members help
11301130

11311131
### DON'T redundantly type annotate initialized local variables
11321132

1133-
{% include 'linter-rule-mention.md', rules:'omit_local_variable_types' %}
1133+
{% render 'linter-rule-mention.md', rules:'omit_local_variable_types' %}
11341134

11351135
Local variables, especially in modern code where functions tend to be small,
11361136
have very little scope. Omitting the type focuses the reader's attention on the
@@ -1237,7 +1237,7 @@ different type annotation conventions, as described in the next two guidelines.
12371237

12381238
### DON'T annotate inferred parameter types on function expressions
12391239

1240-
{% include 'linter-rule-mention.md', rules:'avoid_types_on_closure_parameters' %}
1240+
{% render 'linter-rule-mention.md', rules:'avoid_types_on_closure_parameters' %}
12411241

12421242
Anonymous functions are almost always immediately passed to a method taking a
12431243
callback of some type.
@@ -1268,7 +1268,7 @@ function's parameters. In those cases, you may need to annotate.
12681268

12691269
### DON'T type annotate initializing formals
12701270

1271-
{% include 'linter-rule-mention.md', rules:'type_init_formals' %}
1271+
{% render 'linter-rule-mention.md', rules:'type_init_formals' %}
12721272

12731273
If a constructor parameter is using `this.` to initialize a field,
12741274
or `super.` to forward a super parameter,
@@ -1511,7 +1511,7 @@ void handleError([!void Function()!] operation, [!Function!] errorHandler) {
15111511

15121512
### DON'T specify a return type for a setter
15131513

1514-
{% include 'linter-rule-mention.md', rules:'avoid_return_types_on_setters' %}
1514+
{% render 'linter-rule-mention.md', rules:'avoid_return_types_on_setters' %}
15151515

15161516
Setters always return `void` in Dart. Writing the word is pointless.
15171517

@@ -1528,7 +1528,7 @@ set foo(Foo value) { ... }
15281528

15291529
### DON'T use the legacy typedef syntax
15301530

1531-
{% include 'linter-rule-mention.md', rules:'prefer_generic_function_type_aliases' %}
1531+
{% render 'linter-rule-mention.md', rules:'prefer_generic_function_type_aliases' %}
15321532

15331533
Dart has two notations for defining a named typedef for a function type. The
15341534
original syntax looks like:
@@ -1586,7 +1586,7 @@ it's deprecated.
15861586

15871587
### PREFER inline function types over typedefs
15881588

1589-
{% include 'linter-rule-mention.md', rules:'avoid_private_typedef_functions' %}
1589+
{% render 'linter-rule-mention.md', rules:'avoid_private_typedef_functions' %}
15901590

15911591
In Dart, if you want to use a function type for a field, variable, or
15921592
generic type argument, you can define a typedef for the function type.
@@ -1623,7 +1623,7 @@ that clarity.
16231623

16241624
### PREFER using function type syntax for parameters
16251625

1626-
{% include 'linter-rule-mention.md', rules:'use_function_type_syntax_for_parameters' %}
1626+
{% render 'linter-rule-mention.md', rules:'use_function_type_syntax_for_parameters' %}
16271627

16281628
Dart has a special syntax when defining a parameter whose type is a function.
16291629
Sort of like in C, you surround the parameter's name with the function's return
@@ -1758,7 +1758,7 @@ In Dart, optional parameters can be either positional or named, but not both.
17581758

17591759
### AVOID positional boolean parameters
17601760

1761-
{% include 'linter-rule-mention.md', rules:'avoid_positional_boolean_parameters' %}
1761+
{% render 'linter-rule-mention.md', rules:'avoid_positional_boolean_parameters' %}
17621762

17631763
Unlike other types, booleans are usually used in literal form. Values like
17641764
numbers are usually wrapped in named constants, but we typically pass around
@@ -1872,7 +1872,7 @@ elements to follow.
18721872

18731873
### DO override `hashCode` if you override `==`
18741874

1875-
{% include 'linter-rule-mention.md', rules:'hash_and_equals' %}
1875+
{% render 'linter-rule-mention.md', rules:'hash_and_equals' %}
18761876

18771877
The default hash code implementation provides an *identity* hash—two
18781878
objects generally only have the same hash code if they are the exact same
@@ -1900,7 +1900,7 @@ you're trying to express.
19001900

19011901
### AVOID defining custom equality for mutable classes
19021902

1903-
{% include 'linter-rule-mention.md', rules:'avoid_equals_and_hash_code_on_mutable_classes' %}
1903+
{% render 'linter-rule-mention.md', rules:'avoid_equals_and_hash_code_on_mutable_classes' %}
19041904

19051905
When you define `==`, you also have to define `hashCode`. Both of those should
19061906
take into account the object's fields. If those fields *change* then that
@@ -1912,7 +1912,7 @@ true.
19121912

19131913
### DON'T make the parameter to `==` nullable
19141914

1915-
{% include 'linter-rule-mention.md', rules:'avoid_null_checks_in_equality_operators' %}
1915+
{% render 'linter-rule-mention.md', rules:'avoid_null_checks_in_equality_operators' %}
19161916

19171917
The language specifies that `null` is equal only to itself, and that the `==`
19181918
method is called only if the right-hand side is not `null`.

‎src/content/effective-dart/documentation.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -72,7 +72,7 @@ and uses the special `///` syntax that `dart doc` looks for.
7272

7373
### DO use `///` doc comments to document members and types
7474

75-
{% include 'linter-rule-mention.md', rules:'slash_for_doc_comments' %}
75+
{% render 'linter-rule-mention.md', rules:'slash_for_doc_comments' %}
7676

7777
Using a doc comment instead of a regular comment enables
7878
[`dart doc`][] to find it
@@ -101,7 +101,7 @@ up.
101101

102102
### PREFER writing doc comments for public APIs
103103

104-
{% include 'linter-rule-mention.md', rules:'package_api_docs, public_member_api_docs' %}
104+
{% render 'linter-rule-mention.md', rules:'package_api_docs, public_member_api_docs' %}
105105

106106
You don't have to document every single library, top-level variable, type, and
107107
member, but you should document most of them.
@@ -342,7 +342,7 @@ makes an API easier to learn.
342342

343343
### DO use square brackets in doc comments to refer to in-scope identifiers
344344

345-
{% include 'linter-rule-mention.md', rules:'comment_references' %}
345+
{% render 'linter-rule-mention.md', rules:'comment_references' %}
346346

347347
If you surround things like variable, method, or type names in square brackets,
348348
then `dart doc` looks up the name and links to the relevant API docs.

‎src/content/effective-dart/index.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -105,7 +105,7 @@ that can help you follow a guideline
105105
then the guideline links to those rules.
106106
The links use the following format:
107107

108-
{% include 'linter-rule-mention.md', rules:'unnecessary_getters_setters' %}
108+
{% render 'linter-rule-mention.md', rules:'unnecessary_getters_setters' %}
109109

110110
To learn how to use the linter,
111111
see [Enabling linter rules][]

0 commit comments

Comments
 (0)