Skip to content

Updated Operators section in our Collections guide #6525

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

Open
wants to merge 19 commits into
base: main
Choose a base branch
from

Conversation

antfitch
Copy link
Collaborator

@antfitch antfitch commented Apr 10, 2025

This PR refactors the Operators section of our Collections guide. This change is to prepare for the addition of the null-aware elements for collections.

Preview:

Overview of changes:

  • I've changed the name Operators to Supplementals to make it clear that Operators is not a collection type. Also, this section will need to hold more than operators soon.

  • I have moved each supplemental item into its own section so that they are easier to find in the right TOC.

  • The examples were difficult for me to follow and the output of the examples was not provided. I added output and updated the examples to be easy for someone to copy and paste into DartPad and test.

  • I think we needed to clarify what type of null is supported by our spread operators. Not supported (list = null), Supported (list = [1, null, 2]).

  • I had all of the examples in our excerpt library, but I removed a few that triggered analysis failures due to the following reasons:

    • examples that trigger error cases on purpose (ex: show what happens when you pass a null list into another list using the spread operaton.
    • a value that is helpful for showing something, but never reached in an excerpt. In the following example, 2 is never reached.
    var includeItem = true;
    var items = [0, if (includeItem) 1, if (!includeItem) 2, 3]; // [0, 1, 3]
    

  • I’ve reviewed the contributor guide and applied the relevant portions to this PR.
  • This PR doesn't contain automatically generated corrections or text (Grammarly, LLMs, and similar).
  • This PR follows the Google Developer Documentation Style Guidelines — for example, it doesn't use i.e. or e.g., and it avoids I and we (first person).
  • This PR uses semantic line breaks of 80 characters or fewer.
Contribution guidelines:
  • See our contributor guide for general expectations for PRs.
  • Larger or significant changes should be discussed in an issue before creating a PR.
  • Code changes should generally follow the Dart style guide and use dart format.
  • Updates to code excerpts indicated by <?code-excerpt need to be updated in their source .dart file as well.

@antfitch antfitch requested review from munificent and parlough April 10, 2025 22:07
@antfitch antfitch self-assigned this Apr 10, 2025
@dart-github-bot
Copy link
Collaborator

dart-github-bot commented Apr 10, 2025

Visit the preview URL for this PR (updated for commit 52470f3):

https://dart-dev--pr6525-dart-null-awareness-elements-ujtoc8s3.web.app

Copy link
Member

@munificent munificent left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bunch of feedback here and there but overall I really like the improvement.

@antfitch antfitch marked this pull request as draft April 12, 2025 00:27
@antfitch
Copy link
Collaborator Author

antfitch commented Apr 15, 2025

@parlough I've made some large changes after the first review. Here's an overview:

  • We're now using the term 'element' to describe items in collections.
  • From the discussion above, it seems like all of these supplementals are actually different types of elements that you can add to a collection. I've updated headings to reflect this.
  • I've added a comment above each code sample that does not have an excerpt with a reason. This is so we can keep track of samples that don't have them on purpose.
  • Added the various syntax structures that can be used for each element.
  • Added a new section called Nesting elements that shows various ways you can nest elements. It also sounds like this is a super power of Dart that isn't available in many other languages, so that's pretty cool.
  • I've used one code excerpt per code sample. This was to keep things simple. I've also included a print statement in the excerpts (not visible in code samples) so that we can quickly copy & paste to test the code sample and then update the docs with the results.

Copy link
Member

@parlough parlough left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the extensive work on this @antfitch and for your patience on me reviewing it.

I love these additions, especially the extra examples and showing off more features (else, if-case, nesting, etc).

Overall these additions are a huge improvement. I just have one main concern about the conflation of "element" and some other minor suggestions to consider. Feel free to push back on anything and I'm happy to talk over any of my comments offline as well.

Thanks so much! :D

Comment on lines +50 to +51
Lists use zero-based indexing, where 0 is the index of the first element
and `list.length - 1` is the index of the last element.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change (here and across the page) is what we were purposely trying to avoid in the past as it conflates elements in a collection literal versus actual values in a list.

A single collection element in a collection literal might result in no or even many values in a list, so I think the distinction is still quite important to keep.

I'd be happy to chat through this though.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think that element is the more conventional term that developers are used to seeing.

I'm a huge fan of the Python reference documentation and I love how element is used in these two places:

@munificent what are your thoughts? Also, I am using the term element with the set and map collection types. I hesitated with map, but decided that technically, each key-value pair lives inside of an element in a map. If this is a stretch and not factually correct, let me know.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's what developers might be used to seeing, but I'm not sure that familiarity is worth the confusion from one term being used to mean both syntactical elements in a collection literal and actual values in a list.

When reading the page with "element" being used for both, it is quite confusing for me and I'm familiar with the distinction.

See #2631 (comment) for some other background.

Maybe we could have a call about it?

]; // [oneThing, [multiple_a, multiple_b], things]
```

You can nest all kinds of elements arbitrarily deep.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth clarifying besides the leaf elements (expressions and map entries)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you tell me more? I'm not sure what to update here exactly.

Copy link
Member

@parlough parlough left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much for all of those adjustments and this amazing set of docs @antfitch!

The further changes mostly look great to me and I love that the new snippets have some tests as well. I do think we should consider surfacing those expect calls instead of the comments in the future too ;)

Most of my remaining comments are minor, but I still have some concerns about conflating "element". I left some comments adding more details about why, but we could also have a call to chat more. We could also land your current usages and I could open a follow-up PR with the adjustments I was thinking and we could discuss that. Up to you! :)


void main() {
// #docregion code_sample
dynamic data = 123;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We generally try to avoid using dynamic in code examples, so consider changing the type here to Object.

Suggested change
dynamic data = 123;
Object data = 123;

Another option is just using var or final and ignoring the resulting pattern_never_matches_value_type diagnostic for the file.


void main() {
// #docregion code_sample
var orderDetails = ['Apples', 12, ''];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool sample!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for going back and adding tests for all of these snippets! That will be super helpful for us keeping them up to date and accurate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for reupdating this!

As a note, whenever you update your main branch, if git status shows site-shared as having changes, run git submodule update to update your local submodule to match main.

a comma separated list of expressions or values,
enclosed in square brackets (`[]`).
Here's a simple Dart list:
Dart list literals are denoted by a comma separated list of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Dart list literals are denoted by a comma separated list of
Dart list literals are denoted by a comma-separated list of

return [
executable,
...options,
...extraOptions, // <-- OK now.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this comment state that this is an error, not OK?

Comment on lines +404 to +405
// include the first result, otherwise include the second
// result.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adjusting the break here to better collocate the "otherwise" clause.

Suggested change
// include the first result, otherwise include the second
// result.
// include the first result, otherwise,
// include the second result.

Comment on lines +412 to +413
// include the first result, otherwise, perform the second
// operation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adjusting the break here to better collocate the "otherwise" clause.

Suggested change
// include the first result, otherwise, perform the second
// operation.
// include the first result, otherwise,
// perform the second operation.


### If elements {: #if-element }

You can use an `if` element inside of a collection
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You can use an `if` element inside of a collection
You can use an `if` element inside of a collection literal

Comment on lines +261 to +263
In a collection, an element is an individual item in that
collection. These types of elements are supported in
a collection:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is where the confusion of "element" that I mentioned particularly shows up.

The following h3 subsections are talking about elements in a collection literal, but this intro conflates items in actual collections and the elements in a literal. This mostly affects the usage of "individual item" as the collection elements can result in multiple items.

Suggested change
In a collection, an element is an individual item in that
collection. These types of elements are supported in
a collection:
Collection elements are the syntactical constructs
used within collection literals to define the
resulting collection's initial contents.
These types of elements are supported in a collection:

@parlough parlough marked this pull request as ready for review April 22, 2025 16:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants