Adding SwiftUI implementation of Menu List

[sophialee0416]

Platforms Impacted

• iOS
• macOS

Description of changes

This PR contains the first draft of List (counterpart of UITableView from UIKit), created in SwiftUI. Currently, it supports leading icons, title, and subtitle properties.

Verification

• The TableViewCellVnext Demo Controller uses the same sample data as the non-vNext version. All issues mentioned in PR#330 also pertain to this component.

Pull request checklist

This PR has considered:

• Light and Dark appearances
• VoiceOver and Keyboard Accessibility
• Internationalization and Right to Left layouts
• Different resolutions (1x, 2x, 3x)
• Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)

Microsoft Reviewers: Open in CodeFlow

Microsoft Reviewers: Open in CodeFlow

[harrieshin]

looking at the screenshot this doesn't seem right.
-the singleline cell hight seeems incorrect.

• the title isn't veritcally centered.
• separator should be indented and more aligned with text
• double cell height seem not right too?

[rdeassis]

This file should not be part of the change:
tools/sgen/Pods/Target Support Files/Pods-sgen/Pods-sgen-frameworks.sh

[rdeassis]

I think the variations in the figma should be appearance proxies that extend MSFListTokens.
Once we get the state colors like pressed, hover, etc... this will be a matrix of styles vs states for this color.

[sophialee0416]

#362

[rdeassis]

Are we covering the three line scenario?

[sophialee0416]

As of now, no. We do not have the tokens defined yet, but @Victa should be following up with them later when we need them

[rdeassis]

Sounds good! I think it's worth creating a GitHub issue to track that work item.

[sophialee0416]

#366

[rdeassis]

We'll soon need to add a view as an option to the image (Avatar cell scenario).
Can you create a GitHub issue to track that work?

[sophialee0416]

#365

[rdeassis]

Wouldn't it be nicer to allow the calling code to specify the layout type per cell (in the MSFListVnextCellData)?
We can discuss this after your first merge (it's worth a GitHub issue to track as well).

[sophialee0416]

I wanted to consider both cell design + consistency... should we allow sections to contain cells of different heights or lead users into sticking to uniformity? I agree we should continue this in a discussion, I will create an issue

[sophialee0416]

#367

[rdeassis]

Another thing that can be changed later (GitHub issue):
These values should be tokenized in the YAML file.
Something like:

AP_MSFListTokens:
  cellHeight: [ oneLine: 48, twoLines: 64, threeLines: 84 ]
  ...

[rdeassis]

Since you added the tokens for these, the snippet below should be removed and you should use the tokenized value instead:

var height: CGFloat {
     switch self {
     case .oneLine:
         return 48
     case .twoLines:
         return 64
     case .threeLines:
         return 84
     }
 }

[rdeassis]

What's the benefit of having these types in the MSFListView extension?

[sophialee0416]

It was for organization purposes, but I'm thinking of splitting the file (which will be tracked in a GH issue)

[sophialee0416]

#364

[rdeassis]

Just some last nit comments, but overall looking good! :)

Also, can you remove Pods-sgen-frameworks.sh from the PR?
This is just about the execution permission that won't make any difference if checked in.

[kubalani]

If you are using a custom constraint it would a good idea to not inherit from DemoController and just use UIViewController

[rdeassis]

Thanks for addressing all the comments! :)