Investigate WinRT improvements for updating items, async flow, refiltering items after updates

[joadoumie]

Description of the new feature / enhancement

We need to continue to improve the current state of the world of our WinRT usage. A lot of questions have come up regarding async await patterns + the idea of being able to 'yield' current in PT Run.

This work item includes investigating the Shmueli.WinRT implementation to see what kind of benefits we may be able to get for passing around types.

Scenario when this would be used?

For all things WinRT with extensions.

Supporting information

"Just copying the hacker news http logic, but would be nice to allow extensions to use proper async code... Maybe ties into if we do filtering and are polling extensions less often in the new model, maybe we have a callback pattern for results/updates, so the extension can just spin off a thread to do a search or longer operation, if needed vs. having to just return data right away?"

The discussion revolved around the possibility of extensions returning items with a group string, allowing the UI to handle the grouping instead of extensions having to structure their data. This could be achieved with a public async Task<IEnumberable> Getitems() method, or possibly an IAsyncOperation for WinRT. The extension author could then use yield return to transpose results from another data model to the item.

[zadjii]

This sounds like a combination of a couple different asks:

• Something about use Shmueli.WinRT (tracked in #77)
• Should the return types of the WinRT methods be IAsyncAction<T> vs just T
  • I was under the impression that WinRT's IAsync across processes was Considered Harmful.
  • And I assumed that even a synchronous method implemented out-of-proc could be async in the extension process. (or it doesn't have to be! it's up to the extension). It would just be the responsibility of the hosting app (the WinRT client in this case) to make sure to treat the call as async (it's x-proc)
• Then there's a discussion of how we structure "sections".
  • I'm totally fine switching that to being an optional property on the IListItem itself, rather than a top-level ISection of IListItems. It was kinda hard to implement sections like this.
• The prototype also didn't properly support changes to the list of items yet (ItemsChanged as in the spec IIRC), so that definitely needs to be done

Should we separate some of this out?

[joadoumie]

Yeah this was the top level item that needed to be broken out -- seems like you've done that above, so I'll go ahead and create the additional items and link them here (there is already one for Shmueli).

Based on feedback from Hackathon and folks building extensions -- it'd be interesting if we could make things a bit better for devs by:

• Allowing them to do actual async code @michael-hawker can you help explain more about what you meant by this?
• Using Enumerable vs array/list --> this would allow us to potentially yield results. @plante-msft was looking into file search and it just felt slow because each time you filtered the list of items to return you had to return an array and construct a new array more or less.

[michael-hawker]

It was about using the newer C# IAsyncEnumerable pattern to help synchronize between the extensions and the app to incrementally return results. But talking to Sergio, there's not equivalent WinRT, so that's probably a non-starter?

[joadoumie]

Probably naive question - is that something we can make better in WinRT if it's an important paradigm?

[zadjii-msft]

is that something we can make better in WinRT if it's an important paradigm?

Probably not, certainly not in the timelines we're thinking about.

FWIW I think the best notes I had on the topic are around here: https://github.com/zadjii-msft/PowerToys/blob/main/src/modules/cmdpal/doc/initial-sdk-spec/initial-sdk-spec.md#updating-the-list

[!WARNING] We chose this API surface for a few reasons:

• IObservableCollection, which has quite a good mechanism for specifying exactly which parts of the collection changed, isn't exposed through WinRT
• IObservableVector doesn't work well across process boundaries
• In general, all the collection WinRT objects are Considered Harmful in cross-proc scenarios

But we want both static and dynamic lists to be able to update the results in real-time. Example: A process list that updates in real-time. We want to be able to add and remove items from the list as they start and stop.

---

To mitigate how dumb all that is, the plan I came up with Hart was:

• For a IDynamicListPage, CmdPal will call IListPage.SearchText(string) whenever the search text changes.
  • An extension doesn't need to do anything with that. Like, for example, the Yahoo Fantasy football app doesn't actually start searching for a player till you type three letters. The first two calls to SearchText are just no-ops
• Whenever an extension wants to change its own list of results, it raises an ItemsChanged
  • [A] the extension should store its list of items at this point.
• CmdPal responds to that by calling GetItems on the extension
• the extension replies to GetItems with the items it stashed at [A]

That way, the replies to GetItems should remain quick

(this also doesn't look spec'd very well)

[zadjii-msft]

That however does not deal at all with anything "paginated" though. Like, the HN extension just returns the first 24 items, with no way to indicate "I could have more items for you if you want".

That ^^^^ I had mentally punted out of v0, but maybe we shouldn't

[michael-hawker]

I don't know if it's projected in WinRT, but there is the ISupportIncrementalLoading interface too.

I think that's the crux is how much does the UI pre-filter what it has vs. when it goes to the extension and what does that look like and how we minimize the creation of new/duplicate items:

• in the extension itself (i.e. it keeps its own list between calls - part of this would be examples we create to show best practice here)
• in the UI and the coordination between the items from the extension and what's used by the UI
  • are we able to leverage the objects directly? or have to tie to other objects, etc...
  • During the hackathon, this was made difficult by the nested hierarchy of sections of items vs. deferring the grouping to the UI (though that would assume all the items are of the same 'type').