UWP parser requires "type": "Column" when it's not necessary
See original GitHub issueAccepted, task list:
The following payload will break the UWP parser
{
"type":"AdaptiveCard",
"version":"1.0",
"body":[
{
"type":"ColumnSet",
"columns":[
{
"size":33,
"items":[
{
"type":"Image",
"url":"https://unsplash.it/64?image=1027",
"size":"small",
"style":"person"
}
]
},
{
"size":67,
"contentVerticalAlignment":"center",
"items":[
{
"type":"TextBlock",
"text":"Hi,",
"size":"large"
},
{
"type":"TextBlock",
"text":"MasterHip",
"size":"medium",
"isSubtle":true
}
]
}
]
}
]
}
It breaks simply because each column item doesn’t have "type": "Column"
specified which is redundant and unnecessary, since ColumnSet’s column property is explicitly an array of Column type… the Web visualizer doesn’t break on this.
Issue Analytics
- State:
- Created 6 years ago
- Comments:13 (12 by maintainers)
Top Results From Across the Web
UWP parser requires "type": "Column" when it's not ...
According to http://adaptivecards.io/documentation/#column. The type property is required. If the schema changes, the parser will change ...
Read more >App capability declarations - UWP applications
Most scenarios for app capabilities are relevant only to apps that have package identity, and that run in an AppContainer. All UWP apps...
Read more >Optimize your XAML markup - UWP applications
Parsing XAML markup to construct objects in memory is time-consuming for a complex UI. Here are some things you can do to improve...
Read more >How do I specify a type argument explicitly when reading ...
The compiler can't determine what type T will be. You need to specify it explicitly: Robot robot2 = await XmlIO.XmlRW.
Read more >Column Types in UWP DataGrid (SfDataGrid)
Each column has its own properties and renderer to handle different types of data. You can also add or override existing columns and...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
If we think we could have a different type of column in the future, then I vote for “type” being required. Otherwise, omitting “type” when the type is implicit is a good simplification. We don’t have “type”: “Fact” for a fact in a FactSet for instance.
All works properly.