Currently, `BindingViewStore`s can only directly derive
`BindingViewState` for a view state struct, and then the view store can
derive a binding and use dynamic member lookup to pluck out a field for
a view. This means potentially exposing view state to far more state
than necessary.
To prevent this we can add dynamic member lookup to the binding view
state itself, which allows a view state struct to chip away any state it
doesn't care about.
* Abbreviate nested binding action values
Now that binding action key paths cannot use dynamic member lookup,
dumps are a little more unwieldy to read when nested state is involved.
Generally one can look at the state diff to figure out what changed, so
let's abbreviate the action's state when we can.
* wip
* fixed dismiss action sending when navigating back
* Revert "fixed dismiss action sending when navigating back"
This reverts commit 52f7340406.
* added integration ui test
* fixed id for presentation with `isPresented` parameter
* fixed integration tests
Fixes#2182.
The `id` used for comparison appears to sometimes be `nil`, for example
on macOS when drilling out of a `navigationDestination`. This PR adds a
little nuance to the dismissal logic of `presentationModifier`:
* It explicitly checks that something is presented
* It always sends `dismiss` if the cached `id` was `nil`
We should maybe have some integration tests for macOS for this...
* Fixed BindingAction.set(keyPath:value:) causes equality test on value to fail
* clean up
---------
Co-authored-by: Bharath Booshan <bbooshan@atlassian.com>
Co-authored-by: Brandon Williams <mbrandonw@hey.com>
* Make Send wrap a sendable closure.
* Move Send under the effects docs.
* Fixed a bunch of doc references.
* wip
* wip
* fix
---------
Co-authored-by: Stephen Celis <stephen@stephencelis.com>
* Deprecate `Store.scope(state:)` for view store `observe`
Explicit scoping is most appropriate for transforming domains, which
almost always requires an action transform. In the rare case it doesn't,
we should prefer an explicit `{ $0 }`.
Scoping for the view has been deprecated for awhile for the `observe`
parameter when creating view stores, so let's lead folks that direction.
* wip
* wip
For some reason, using `memcmp` with an empty ordered set and a
non-empty ordered set returns true:
```swift
areOrderedSetsDuplicates([1, 2, 3], []) // true
```
Because of this, we should always check the count before delegating to
`memcmp`. We should also be on the lookout for other exceptions in case
`memcmp` is not appropriate to use here.
Runtime warnings are not test helpers that should propagate XCTest
failures to the original file/line, so we should always omit that
information. This leads to better test failures that show up alongside
the test, not buried in application code.
* Pass state to `SwitchStore.init` view builder
Rather than rely on many, many overloads of `SwitchStore.init` to
strictly accept only `CaseLet`s and an optional, final `Default` view,
let's introduce a single initializer without constraints that is passed
the current state whenever the case changes. This state can be switched
on and route to the appropriate view via `CaseLet`.
The pros:
* We get exhaustive switching at compile time.
* We get more flexibility in the view layer. Previously, any
customization needed to be pushed into the `CaseLet` builder, but
now `CaseLet` can freely apply view modifiers.
* We can deprecate and eventually remove the many, many initializer
overloads, and hopefully slim down binary size in the process, and
improve view builder compile times when dealing with `SwitchStore`.
We can also deprecate and eventually remove `Default`.
The cons:
* It's slightly more verbose and repetitive. You have a `SwitchStore`
and then a `switch` inside it with many `case`s with `CaseLet`s
inside them, and the `case .screen:` is followed by
`CaseLet(/State.screen, ...)`.
* One is free to extract the state's associated value(s) and use it to
render a view, but this view will be inert and will not re-render if
the value it depends on changes in the store. This can lead to some
surprises, but we can document against the pattern, and maybe in the
future we can use something like macros to prevent this from being
possible.
* You can still get things wrong if you're not careful: there's
nothing enforcing that the `case` you switch on is the same case you
send to `CaseLet`, so `case .screenA: CaseLet(/State.screenB, ...)`
is possible. While unlikely, it's still a copy-paste error in
waiting.
* wip
* wip
* wip
* Bump
* fix test
* clean up
* clean up
* clean up
* wip
---------
Co-authored-by: Brandon Williams <mbrandonw@hey.com>
* `IfLetStore`: ignore view store binding writes to `nil` state
* swift-format
* wip
* add test for filter
---------
Co-authored-by: Brandon Williams <mbrandonw@hey.com>
The -`able` naming evokes protocols in Swift, and is an outlier when
considered alongside the rest of TCA's binding tools:
- `BindingAction`: concrete type
- `BindableAction`: protocol
- `BindingReducer`: concrete type
So, let's make things consistent.
The one caveat is that Swift diagnostics for such a deprecation aren't
great, so users won't get proactive warnings here for the time being:
https://github.com/apple/swift/issues/63139
We may just want to keep the deprecation around till it does...
It occurred to us that this solution unfortunately is incompatible with
view actions. We have an alternate solution that works, so I'll PR that
in the future if no others materialize!
