Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate from include to render where possible #5770

Merged
merged 2 commits into from
May 6, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/_includes/head.html
Original file line number Diff line number Diff line change
Expand Up @@ -97,5 +97,5 @@
{% endfor -%}
{% endif -%}

{% include 'analytics.html' -%}
{% render 'analytics.html' -%}
</head>
2 changes: 1 addition & 1 deletion src/_includes/page-header.html
Original file line number Diff line number Diff line change
Expand Up @@ -10,4 +10,4 @@ <h4 class="text-center">
{% endif -%}
{% endif -%}
</header>
{% if site.show_banner -%} {% include 'banner.html' %} {%- endif -%}
{% if site.show_banner -%} {% render 'banner.html' %} {%- endif -%}
6 changes: 3 additions & 3 deletions src/_layouts/default.html
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,8 @@
{% endif -%}
{% endif -%}
<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 %}">
{% include 'cookie-notice.html' %}
{% include 'gtags.html' %}
{% render 'cookie-notice.html' %}
{% render 'gtags.html' %}
{% include 'page-header.html', obsolete:obsolete %}
{% include 'navigation-side.html' %}
<main id="page-content">
Expand Down Expand Up @@ -38,6 +38,6 @@ <h1>{{title }}</h1>
</div>
</article>
</main>
{% include 'page-footer.html' %}
{% render 'page-footer.html' %}
</body>
</html>
6 changes: 3 additions & 3 deletions src/_layouts/error.html
Original file line number Diff line number Diff line change
Expand Up @@ -2,15 +2,15 @@
<html lang="en">
{% include 'head.html' %}
<body class="{{layout}} hide_toc">
{% include 'cookie-notice.html' %}
{% include 'gtags.html' %}
{% render 'cookie-notice.html' %}
{% render 'gtags.html' %}
{% include 'page-header.html' %}
{% include 'navigation-side.html' %}
<main id="page-content">
<div class="content">
{{content}}
</div>
</main>
{% include 'page-footer.html' %}
{% render 'page-footer.html' %}
</body>
</html>
6 changes: 3 additions & 3 deletions src/_layouts/homepage.html
Original file line number Diff line number Diff line change
Expand Up @@ -2,13 +2,13 @@
<html lang="en">
{% include 'head.html' %}
<body class="homepage">
{% include 'cookie-notice.html' %}
{% include 'gtags.html' %}
{% render 'cookie-notice.html' %}
{% render 'gtags.html' %}
{% include 'page-header.html' %}
{% include 'navigation-side.html' %}
<main id="page-content">
{{content}}
</main>
{% include 'page-footer.html' %}
{% render 'page-footer.html' %}
</body>
</html>
2 changes: 1 addition & 1 deletion src/content/codelabs/async-await.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ Estimated time to complete this codelab: 40-60 minutes.

:::note
This page uses embedded DartPads to display examples and exercises.
{% include 'dartpads-embedded-troubleshooting.md' %}
{% render 'dartpads-embedded-troubleshooting.md' %}
:::

The exercises in this codelab have partially completed code snippets.
Expand Down
2 changes: 1 addition & 1 deletion src/content/codelabs/dart-cheatsheet.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ for an explanation and the answer.

:::note
This page uses embedded DartPads to display runnable examples.
{% include 'dartpads-embedded-troubleshooting.md' %}
{% render 'dartpads-embedded-troubleshooting.md' %}
:::

## String interpolation
Expand Down
2 changes: 1 addition & 1 deletion src/content/codelabs/iterables.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ Estimated time to complete this codelab: 60 minutes.

:::note
This page uses embedded DartPads to display examples and exercises.
{% include 'dartpads-embedded-troubleshooting.md' %}
{% render 'dartpads-embedded-troubleshooting.md' %}
:::

The exercises in this codelab have partially completed code snippets.
Expand Down
44 changes: 22 additions & 22 deletions src/content/effective-dart/design.md
Original file line number Diff line number Diff line change
Expand Up @@ -340,7 +340,7 @@ previous guidelines state, either:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Method cascades are a better solution for chaining method calls.

Expand Down Expand Up @@ -1049,7 +1049,7 @@ various cases, but the rough summary is:

### DO type annotate variables without initializers

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

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

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

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

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

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

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

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

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

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

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

### DON'T type annotate initializing formals

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

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

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

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

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

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

### DON'T use the legacy typedef syntax

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

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

### PREFER inline function types over typedefs

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

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

### PREFER using function type syntax for parameters

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

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

### AVOID positional boolean parameters

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

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

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

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

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

### AVOID defining custom equality for mutable classes

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

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

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

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

The language specifies that `null` is equal only to itself, and that the `==`
method is called only if the right-hand side is not `null`.
Expand Down
6 changes: 3 additions & 3 deletions src/content/effective-dart/documentation.md
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@ and uses the special `///` syntax that `dart doc` looks for.

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

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

Using a doc comment instead of a regular comment enables
[`dart doc`][] to find it
Expand Down Expand Up @@ -101,7 +101,7 @@ up.

### PREFER writing doc comments for public APIs

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

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

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

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

If you surround things like variable, method, or type names in square brackets,
then `dart doc` looks up the name and links to the relevant API docs.
Expand Down
2 changes: 1 addition & 1 deletion src/content/effective-dart/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -105,7 +105,7 @@ that can help you follow a guideline
then the guideline links to those rules.
The links use the following format:

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

To learn how to use the linter,
see [Enabling linter rules][]
Expand Down
Loading