-
Notifications
You must be signed in to change notification settings - Fork 719
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
base: main
Are you sure you want to change the base?
Conversation
Visit the preview URL for this PR (updated for commit 52470f3): https://dart-dev--pr6525-dart-null-awareness-elements-ujtoc8s3.web.app |
There was a problem hiding this 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.
examples/misc/lib/language_tour/misc/null_aware_spread_operator_in_collection_a.dart
Outdated
Show resolved
Hide resolved
examples/misc/lib/language_tour/misc/null_aware_spread_operator_in_collection_a.dart
Outdated
Show resolved
Hide resolved
@parlough I've made some large changes after the first review. Here's an overview:
|
There was a problem hiding this 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
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- https://docs.python.org/3/library/stdtypes.html#lists
- https://docs.python.org/3/library/stdtypes.html#common-sequence-operations
@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.
There was a problem hiding this comment.
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?
examples/misc/lib/language_tour/misc/for_loop_in_collection_a.dart
Outdated
Show resolved
Hide resolved
]; // [oneThing, [multiple_a, multiple_b], things] | ||
``` | ||
|
||
You can nest all kinds of elements arbitrarily deep. |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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.
Co-authored-by: Parker Lougheed <[email protected]>
Co-authored-by: Parker Lougheed <[email protected]>
Co-authored-by: Parker Lougheed <[email protected]>
Co-authored-by: Parker Lougheed <[email protected]>
Co-authored-by: Parker Lougheed <[email protected]>
Co-authored-by: Parker Lougheed <[email protected]>
There was a problem hiding this 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; |
There was a problem hiding this comment.
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
.
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, '']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool sample!
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
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?
// include the first result, otherwise include the second | ||
// result. |
There was a problem hiding this comment.
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.
// include the first result, otherwise include the second | |
// result. | |
// include the first result, otherwise, | |
// include the second result. |
// include the first result, otherwise, perform the second | ||
// operation. |
There was a problem hiding this comment.
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.
// 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use an `if` element inside of a collection | |
You can use an `if` element inside of a collection literal |
In a collection, an element is an individual item in that | ||
collection. These types of elements are supported in | ||
a collection: |
There was a problem hiding this comment.
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.
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: |
This PR refactors the
Operators
section of ourCollections
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
toSupplementals
to make it clear thatOperators
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:
Contribution guidelines:
dart format
.<?code-excerpt
need to be updated in their source.dart
file as well.