feat: Add a way to display search suggestions

[RemiBardon]

It was initially in #76, but I separated the two features.

• Add preview app in Makefile

@nesium's TODO-list proposition (modified a bit):

1. TCA-driven TextView + Reducer

#119

2. AutoSuggest reducer and environment

• The environment we have basically
• The reducer is missing (like the one I sent you in the Gist)
• The reducer accepts an action that contains a search query, then performs the search via its environment
• Handles loading, error and empty states

2.1 AutoSuggest list

• Create a wrapper around feat: Create CustomList #85

3. SwiftUI window

• A custom container view in the same shape as .alert() or .popover()
• Takes only a View for its content and a Bool Binding to determine if the window is presented or not
• It would be fantastic if the window could be closed on click outside, but that could require serious hackery (e.g. swizzling NSApp.sendEvent). But maybe there is an easy solution? Misc.: Escape to close sheets #86

4. ContactSuggestionField (or actually just a reducer)

• It's a data-only component
• The view is composed from scratch where we need it to handle the case where search results are either displayed inline or in a popover (window)
• Composes the TCA-driven TextView reducer and AutoSuggest reducer
• Feeds events into the respective reducer by providing relatively little glue code
• Manipulates the focus when receiving up/down key events by using the convenience methods in the AutoSuggestList state
  vCloses the window when escape is pressed
• Inserts token from list selection when return is pressed or an item in the list is clicked
• Can be hard-coded to contacts for now, we can make it generic when we need it
• Sets a Bool when it "thinks" that the window with results should be presented/dismissed but its only a hint since the list could be displayed inline

[RemiBardon]

Selects the next responder when Tab is pressed

@nesium Why wouldn't this already work? We do not intercept Tab events 🤔

[nesium]

Selects the next responder when Tab is pressed

@nesium Why wouldn't this already work? We do not intercept Tab events 🤔

Is that default NSTextView behavior? Have you tried it?

[RemiBardon]

Is that default NSTextView behavior? Have you tried it?

Yes it is, as long as you check the System Preferences > Keyboard > Shortcuts > "Use keyboard navigation to move focus between controls" checkbox.

I don't know why it's not the default, but it's there.

[RemiBardon]

There are too many commits cluttering the PR, let me rebase this correctly.

[RemiBardon]

There are still many added files, but I will remove most of them before marking this PR as ready.

[RemiBardon]

Here is a recording of the attached window:

Screen.Recording.2022-07-20.at.11.58.31.mov

What you should see:

• The List has a background which cannot be removed in plain SwiftUI, which in addition creates square corners.
  • I had to clip the shape, using the window's corners (which I defined)
  • The background color changes between the list state and the empty state
• Keyboard navigation works, but it's custom listening to ↑, ↓ and ↵ and across-section index selection
  • It has to be custom because the text field takes the first responder, and I could not work around it (it could surely be done in AppKit, but I didn't try hard).
• I added a .onTapGesture to list rows, to allow manual selection, but the list has it's own selection, with a larger hit testing shape.
  • I'm not sure I can use the same shape in a flexible manner (I could hard code a content shape, or use Rectangle().scale(1.5), but I'm not a fan of it.
  • I don't think we really care anyway.
• SwiftUI Lists are always scrollable (until iOS 16 IIRC), which means the List doesn't have a useful intrinsic content size (even using .fixedSize), which in turn means the window height has to be computed by hand…
  • I used the standard row and header sizes, which means that if we introduce rows of a different size, it will start scolling (or be too big)
• The first list section header is sticky, even though the list has the correct size to be non-scrollable
  • I don't think it's possible to disable this ATM
• Using a VStack would fix most issues related to Lists, but it would also mean loosing all the native benefits of Lists, and maintaining two layouts (VStack for the attached window but probably keep the List for the non-window suggestions)…
  • We could also have a custom NSTableView / UITableView wrapper with a custom style. From what I see, the Finder search bar and the Xcode autocompletion windows both use either a custom list or a VStack with a style similar to the native lists.

I think that's all I wanted t note 🤔

[RemiBardon]

This is nice 🙂

Screen.Recording.2022-07-26.at.15.52.43.mov

No more height computation, no more manual clipping, no more background color…