This was started in #48

Still some minor work to do here around design and determination of whether there will be model objects representing the section itself.

Tracking new NSTableView bindings with similar to our CollectionViewController.

1. Async.debounce doesn't actually wait (see aa6c8ed)
2. Async.throttle will swallow an invocation that happens during the reset window for the previous, this is unexpected. Either fix or remove.

If state changes (e.g. from .loading(someModel) to .loaded(someModel) but there are no diff engine deltas, the hasUpdates check below prevents the state from being committed.

In practice, this is rare - but needs to be fixed. We also need to flesh out the tests in this area to be confident about future changes.

    fileprivate func applyCurrentDataToCollectionView() {
        precondition(collectionViewState == .synced)

        let (updates, commitCollectionChanges) = currentCollection.beginUpdate(underlyingCollection)
        guard updates.hasUpdates else {
            // still synced
            // no need to update lastKnownCollectionViewContents
            return
        }

https://github.com/dropbox/pilot/blob/master/UI/Source/CollectionViews/CollectionViewModelDataSource.swift#L460

From @danielrhammond 's comment in #109 :

random idea, but since we do a lot of things like this in our app it might be nice to provide an optional protocol CVCs can conform to with some static funcs which if conformed to provide a convenience init(context:) initializer

static func defaultModel() -> ModelCollection
static func defaultLayout() -> NSCollectionViewLayout
static func viewBinder() -> ViewBindingProvider

Need to split our Pilot-Target.xcconfig into a two platform specific files so they can inherit from the correct base framework config.

Right now ViewModelUserEvent.click actually gets sent on mouse down.

Opening the bug for discussion/figuring out the best plan. FWIW, most people should probably use .select as it covers more edge cases. But .click is used for menu-style UIs and autocomplete-type windows.

Here

It's easy to get bitten with a struct ViewModel since it gets copied by value within the data sources.

Preliminary investigation tracking down app crash suggests theres a seg fault when going from .loading(nil) to .loaded([[...]]) which is alleviated by always starting with a single empty section (.loading([[]]))

Needs help tracking down whether this is a radar'able NSCV bug and/or something that needs to be addressed in pilot.

Ideally, view models will handle the core ability to support peek/pop via a new ViewModelUserEvent - but most of the handling will need to happen at the UIKit layer.

• CollectionViewController handles registerForPreviewing/unregisterForPreviewing
• Since the previewing APIs need a UIViewController returned synchronously, we'll need to figure out the best way to let the higher app layers actually return it (potentially closures on the CVC to generate/commit a preview VC from a view model aeek action.

Basically https://github.com/dropbox/pilot/blob/master/Core/Source/MVVM/SimpleModelCollection.swift#L78 needs to add an empty section [.loaded([])] if there are no sections at all since flattenedState treats [] as .notLoaded

Which leads to the surprising interaction where a consumer sends an empty load that is interpreted as content never having loaded.

selected has issues when you subclass an Objective-C NSView or UIView with an isSelected getter (example is NSTableRowView) and also conform it to View.

The synthesized swift name (isSelected) cannot coexist with the View conformance selected.

This seemed to work ok in Swift <3.2, but no longer works in Swift 3.2+.

We should move this to an emum of selectionStyle to match highlightStyle. This will also give us a bit more flexibility in types of selection state.

We should also give NSView and UIView classes that have a selected property easy free implementations of selectionState.

This is a breaking change.

https://www.dropbox.com/scl/fi/chwd2p6occ6wx6pkepxhg/screenshot%202017-06-07%2017.49.16.png?dl=0

Post-flattening, consolidate code and sanity check.

Flesh out the views for the mac example app

Building on the work in #157 we can remove ModelVersion and ModelVersionMixer entirely from Pilot by making model conform to Hashable as part of its requirements.

Pros:

• Very common that we want Hashable (or at bare minimum Equatable) for our models,
• Swift 4.2 autogen'ing conformance for simple structs makes this not a pain for most models
• Makes things feel more swifty (having a separate hasher is definitely a drag in the post 4.2 world)

Cons:

• Forces Equatable for models (not sure this is actually bad but could be perceived to be higher bar than ModelVersion implementation)
• Can't separate out hashing for pilots benefit from generic hashing function (this is mostly a good thing, but we exploited this once or twice in $RIP_SECRET_PROJECT to drop noisy user updates for example)
• Breaking change

I'm solidly pro but wanted to check for feedback before proceeding (cc @wkiefer)

And wiring up in CollectionViewController. Could consider this an .open action to be a bit more generic.

It would be great to allow a CollectionSupportingView to be able to invalidate it's own layout in response to some view state that changes it's bounds.

Eg. a input text field that grows in height as the user types.

See #102 for a naive implementation.

That implementation needs 2 things to be generally useful in pilot:

1. It should only invalidate the layout of the single view (not the whole CV)
2. It should have a more robust way of getting a reference to the collectionView.

Make sure it builds on Xcode 8 and 9beta

Initial work for this happened in #48

Remaining

• Update Examples/iTunesSearch

Tracking new UITableView bindings with similar to our CollectionViewController.

Tracking overal merge of https://github.com/dropbox/pilot/tree/0.9-dev into master

The change to when the CurrentCollection state was updated in #19 causes issues with changes to state in the underlying ModelCollection. Especially when going from notLoaded to loading(_) for example.

The CurrentCollection state is now updated in a commit closure however it's not guaranteed this closure will be called, which means sometimes state changes are swallowed. For example in:

let (updates, commitCollectionChanges) = currentCollection.beginUpdate(underlyingCollection)
guard updates.hasUpdates else {
  // still synced
  // no need to update lastKnownCollectionViewContents
  return
}

In this case a ModelCollection going from notLoaded to loading will have no updates and so the underlying state will never be updated and the CollectionViewController won't display a loading spinner.

As part of the 0.9 release, we'll be consolidating the breaking changes from #52 with breaking ModelCollection renames.

Tasks

• Complete Table Below

Discussed offline but we have a common pattern in our app is to add a feature the the view controller to select a certain model when the model collection first loads (if no other selection exists), would be nice to add support for that in pilot.

Just a random github user browsing around. Did you guys stop supporting this? @wkiefer

From internal comment/bug:

iOS assigns accessibilityDragSourceDescriptors and accessibilityDropPointDescriptors to the cell, but doesn't look up the hierarchy from elements to their ancestors to see if drag and drop applies, If this cell were directly isAccessibilityElement = YES then this would not be a problem, but since we're hosting something else which (may be) an accessibility element, we need to find it and copy over the location descriptors so drag&drop applies.

So CollectionViewHostCell needs to set these properties on its host view (and maybe on the child View itself too?)

Currently we only support click and right click events, double click would be a useful addition to the macOS platform as it currently has to be manually implemented by each view outside of the regular user event handling.

Currently if you print a model collection state you get all the models along for the ride, thats unlikely to be useful in most non-trivial cases.