Lasso is an iOS application architecture for building discrete, composable and testable components both big and small - from single one-off screens, through complex flows, to high-level application structures.
Without a set of structural principles, it's very easy for an application's code base to become hard to both reason about, and maintain. In particular, these problems will eventually arise:
Lasso encourages a strong separation of concerns by clearly defining discrete, single-responsibility components where specific types of code should live, and a clear, flexible way for these components to communicate. Larger units of behavior are easily composed, and re-composed.
We generally think of a screen as a single page/view in an app - e.g., a login view, a contacts list view, an audio settings view, etc.
In Lasso, a
Screen is the collection of types used to implement a single view:
View (i.e., a
UIViewController) is responsible for:
State(i.e., the content) of the screen
Store(i.e., the decision maker)
Lasso views tend to be small, with practically zero logic in them.
A unidirectional data flow is used to ensure consistency: a
View never re-renders anything in direct response to a user action.
Actions to the
Store, which updates the
State, which come back to the
State change notifications.
Store is where a screen's decisions are made, and is the source of truth for the screen's
Store is responsible for:
Actions(i.e. events sent from the
Store can also generate an
Output when an event occurs that is more appropriately handled elsewhere. E.g., a login screen might generate a "user did login" output as a signal to a higher-level system to move to a logged-in portion of an app; or a contact list screen might generate a "did select contact" output as a signal to a higher-level flow to either present or push a contact detail screen.
Flow represents a feature - or area - of an app, and is commonly composed of a collection of
Screens. For example, a "new user" flow might be composed of a series of one-time informational screens followed by a single "let's get started" screen.
Flow is instantiated and started within an appropriate context of a view hierarchy (e.g., a "sign up" flow might be presented on a menu screen, or a "welcome" flow might be pushed onto a navigation stack). The
Flow starts by creating its initial
Screen, and listens for
Output signals. As
Outputs arrive, the
Flow decides what to do with them - it can create and place another
Screen into the view hierarchy, emit its own
Output (when an event occurs that is more appropriately handled elsewhere), or whatever is appropriate for the
Flows are encapsulated modules with discrete entry and exit points, it's quite easy and common for a
Flow to manage both
Flows. In this way, it becomes possible to define your application as a hierarchy of components, reducing complexity from the top level down.
To run the example project
pod installfrom the
Lasso supports iOS 13 and up, and can be compiled with Swift 4.2 and up.
Note: Lasso v.1.3.0 has added support for SwiftUI, and has a minimum deployment target of iOS 13.0. If you need support for earlier versions of iOS, please use v1.2.1.
The core Lasso framework is added to the primary target in your Podfile:
LassoTestUtilities to your test target(s):
The Lasso package URL is:
For sample usage, see: Swift Package Manager Sample.
We love contributions!
If you have a feature in mind, and/or have found a bug, the best thing to do is:
Lasso is licensed under the Apache-2.0 Open Source license.
You are free to do with it as you please. We do welcome attribution, and would love to hear from you if you are using it in a project!
|Last commit: 2 weeks ago|
Adds a way to configure the time out for view life cycle assertions (
This configuration is per XCTestCase subclass. For more granular control, the pre-existing
timeout parameters can be used.
To override the timeout for an
XCTestCase subclass, add
AssertionTimeoutOverride conformance to your subclass, and provide a value for
defaultLassoAssertionTimeout to use a custom timeout.