Skip to content

Catch some typos in Articles #2088

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 7, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ confirmation dialogs, and even custom forms of navigation that are not handed do
So, for the purposes of this documentation, we will use the following loose definition of
"navigation":

> Defintion: **Navigation**: A change of mode in the application.
> Definition: **Navigation**: A change of mode in the application.

Each of the examples we considered above, such as drill-downs, sheets, popovers, covers, alerts,
and more, are all a "change of mode" in the application.
Expand Down Expand Up @@ -239,7 +239,7 @@ stack. This means the features can be put into their own modules with no depende
other, and can be compiled without compiling any other features.

* The `NavigationStack` API in SwiftUI typically has fewer bugs than `NavigationLink(isActive:)` and
`navigationDestiation(isPresented:)`, which are used in tree-based navigation. There are still a
`navigationDestination(isPresented:)`, which are used in tree-based navigation. There are still a
few bugs in `NavigationStack`, but on average it is a lot more stable.

#### Cons of stack-based navigation
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -471,7 +471,7 @@ Doing this with exhaustive testing is verbose, and there are a few problems with
* We need to be intimately knowledgeable in how the login feature works so that we can assert
on how its state changes and how its effects feed data back into the system.
* If the login feature were to change its logic we may get test failures here even though the logic
we are acutally trying to test doesn't really care about those changes.
we are actually trying to test doesn't really care about those changes.
* This test is very long, and so if there are other similar but slightly different flows we want to
test we will be tempted to copy-and-paste the whole thing, leading to lots of duplicated, fragile
tests.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -76,7 +76,7 @@ struct InventoryFeature: ReducerProtocol {

> Note: The key path used with `ifLet` focuses on the `@PresentationState` projected value since it
uses the `$` syntax. Also note that the action uses a [case
path](http://github.com/pointfreeco/swift-case-paths), which is analagous to key paths but tuned
path](http://github.com/pointfreeco/swift-case-paths), which is analogous to key paths but tuned
for enums, and uses the forward slash syntax.

That's all that it takes to integrate the domains and logic of the parent and child features. Next
Expand Down