I have a property with a fixed type
var statusPublisher: Published<Status>.Publisher
and some other statuses like substatus1, substatus2
and I want it to combine values of other statuses like
var statusPublisher: Published<Status>.Publisher {
$substatus1.combineLatest($substatus2).map { s1, s2 -> Status in ... }
}
but it says Cannot convert return expression of type 'Publishers.CombineLatest<Published<Substatus1>.Publisher, Published<Substatus2>.Publisher>' to return type 'Published<Status>.Publisher'
I managed to workaround it with one extra
var connectionStatusSubject = PassthroughSubject<Status, Never>()
that I put into
var connectionStatusPublisher: AnyPublisher<Status, Never> {
connectionStatusSubject.eraseToAnyPublisher()
}
with new AnyPublisher here, but it seems not so neat.
Is there any way to make it the right way?
Published<T>.Publisher is just a specific type of a publisher, created by #Published property wrapper. There's no reason at all to use that as the type of the computed property.
Type-erase to AnyPublisher - like you did with PassthroughSubject - except you don't need a PassthroughSubject:
var statusPublisher: AnyPublisher<Status, Never> {
$substatus1
.combineLatest($substatus2)
.map { s1, s2 -> Status in ... }
.eraseToAnyPublisher()
}
Related
We like the auto equality behavior of struct, by just simply conform Equatable protocol.
Sometimes, we would like to exclude some properties out from struct equality comparison.
Currently, this is the method we are using.
struct House: Equatable {
var field_0: String
var field_1: String
...
var field_50: String
static func == (lhs: House, rhs: House) -> Bool {
if lhs.field_0 != rhs.field_0 { return false }
if lhs.field_1 != rhs.field_1 { return false }
...
if lhs.field_48 != rhs.field_48 { return false }
// Ommit field_49
if lhs.field_50 != rhs.field_50 { return false }
return true
}
}
But, such methodology is pretty error prone, especially when we add in new field in the struct.
Is there a way to exclude certain properties fields from equality comparison, without writing our own == function?
Is there a way to exclude certain properties fields from equality comparison, without writing our own == function?
No. At present, the only alternative to automatic synthesis of Equatable conformance is good old fashioned writing code.
There is a solution using Swift Property Wrapper feature actually. It's described here.
Basically what you need is to define next property wrapper
#propertyWrapper
struct EquatableNoop<Value>: Equatable {
var wrappedValue: Value
static func == (lhs: EquatableNoop<Value>, rhs: EquatableNoop<Value>) -> Bool {
true
}
}
And use it like next
struct Test: Equatable {
var a: Int
#EquatableNoop
var b: () -> Void
}
I'm using Future to create a publisher that returns a single value from outside of the future creation closure. For this, I store the promise property locally:
return Future<Something, Never> { promise in
self.somePromise = promise
}.eraseToAnyPublisher()
Then after some work is finished I resolve the promise:
self.somePromise(.success(data))
I've searched the documentation and haven't found any references, is this a correct usage or is there a better way to do it?
To put it more into context, my idea is to have some kind of "broker" class, that returns promises and that at some time in the future will publish a result:
class FruitBroker {
// MARK: - Private Properties
private var applePromise: Future<[Apple], Never>.Promise!
private var orangePromise: Future<[Orange], Never>.Promise!
// MARK: - Methods
func getApples() -> AnyPublisher<[Apple], Never> {
return Future<[Apple], Never> { promise in
self.applePromise = promise
}.eraseToAnyPublisher()
}
func getBananas() -> AnyPublisher<[Orange], Never> {
return Future<[Orange], Never> { promise in
self.orangePromise = promise
}.eraseToAnyPublisher()
}
// MARK: - Private Methods
private func onHarvestFinished() {
applePromise(.success(apples))
orangePromise(.success(oranges))
}
}
This looks like a situation where you should just use PassthroughSubject or CurrentValueSubject:
class FruitBroker {
var applePublisher = PassthroughSubject<[Apple],Never>()
var orangePublisher = PassthroughSubject<[Orange],Never>()
private func onHarvestFinished(apples: [Apple], oranges: [Orange]) {
applePublisher.send(apples)
orangePublisher.send(oranges)
}
}
is this a correct usage
No. What you're doing is not Combine. Combine is publisher -> operators -> subscriber, where this path constitutes a pipeline. You have no pipeline. You're just storing a method and later calling it; you don't need a Combine Future to do that.
I would like to create a property wrapper for CurrentValueSubject. I have done this like that:
#propertyWrapper
public class CurrentValue<Value> {
public var wrappedValue: Value {
get { projectedValue.value }
set { projectedValue.value = newValue }
}
public var projectedValue: CurrentValueSubject<Value, Never>
public init(wrappedValue: Value) {
self.projectedValue = CurrentValueSubject(wrappedValue)
}
}
This works but there is a little thing I would like to change with it - use struct instead of class. The problem with using struct for this is that sometimes I could get Simultaneous accesses error. And I know why, this happens when in sink from this publisher I would try to read the value from wrapped value. So for example with code like this:
#CurrentValue
let test = 1
$test.sink { _ in
print(self.test)
}
And I more or less know why - because when projectedValue executes its observation, wrapped value is still in process of setting its value. In class this is ok, because it would just change the value, but with struct it actually modifies the struct itself, so Im trying to write and read from it at the same time.
My question is - is there some clever way to overcome this, while still using struct? I don't want to dispatch async.
Also I know that #Projected works similarly to this propertyWrapper, but there is a big difference - Projected executes on willSet, while CurrentValueSubject on didSet. And Projected has the same issue anyway.
I know that I can read the value inside the closure, but sometimes Im using this with various function calls, that might eventually use self.test instead.
Try my implementation
#propertyWrapper
class PublishedSubject<T> {
var wrappedValue: T {
didSet {
subject.send(wrappedValue)
}
}
var projectedValue: some Publisher<T, Never> {
subject
}
private lazy var subject = CurrentValueSubject<T, Never>(wrappedValue)
init(wrappedValue: T) {
self.wrappedValue = wrappedValue
}
}
Is there a way to call an async function from a lazy or computed property?
struct Item {
lazy var name: String = {
API.requestThing({ (string: String) in // Xcode didn't like this
return string // this would not work here
})
}()
}
class API {
class func requestThing(completion: String -> Void) {
completion("string")
}
}
Your completion handler in API.requestThing returns a String, yet it is supposed to have no return value:
(completion: String -> Void)
I got this to work:
struct Item {
lazy var name: String = {
API.requestThing({ (string: String) in
return string
})
}()
}
class API {
class func requestThing(completion: String -> String) -> String {
return completion("string")
}
}
There is no good reason to use "lazy" in this case. lazy is for initialization. Just create a normal func and pass a completion handler.
First, requestThing returns () (ie void) and not String. So the type of the following expression is also () and not String:
API.requestThing { string in
return string
}
Second, the call to requestThing is asynchronous, so even if you defined name as a lazy var, the call to the var body function is still synchronousand will return immediately.
So if you can transform name into a function like this:
func name(completion: String -> ()) {
API.requestThing { string in
completion(string)
}
}
// Later you call it in this way
myItem.name { name in
// use the value of name
}
If in addition you want to cache the retrieved value you can modify Item to a class and use the following code
class Item {
private var nameValue: String?
func name(completion: String -> ()) {
if let value = nameValue {
// return cached value
return completion(value)
} else {
// request value
API.requestThing { string in
// cache retrieved value
self.nameValue = string
// return retrieved value
completion(string)
}
}
}
}
There's probably no compelling reason to do this, but the following approach seems to be reasonable:
Instead having a variable of type String - we sometimes require a "Future" of that thing, e.g. Future<String>. A future represents the eventual result of an asynchronous operation - that is exactly what's given in your question.
The future itself is a "normal" variable and can be lazy evaluated, too. It just doesn't yet have its eventual value. That means, the underlying task will only be started when explicitly requested (e.g. lazily). From a design or architectural point of view, this may make sense.
func fetchString() -> Future<String> { ... }
lazy var name: Future<String> = fetchString()
Later in your code, you obtain the variable as follows:
item.name.map { string in
print(string)
}
If this is the first access to the lazy property, it will start the underlying asynchronous operation which calculates the string. Then, when the variable is available, the mapping function as provided in the map function will be called with the variable as an argument - possibly some time later, too.
Otherwise (if this is not the first access), it will just provide the string in the parameter when it is available, possibly immediately.
Since operations may fail, a "Future" also provides means to handle this:
item.name.map { string in
print(string)
}.onFailure { error in
print("Error: \(error)")
}
See also: https://en.wikipedia.org/wiki/Futures_and_promises
There are implementations for Futures in Swift and Objective-C, also often called "Promise".
As an exercise in learning I'm rewriting my validation library in Swift.
I have a ValidationRule protocol that defines what individual rules should look like:
protocol ValidationRule {
typealias InputType
func validateInput(input: InputType) -> Bool
//...
}
The associated type InputType defines the type of input to be validated (e.g String). It can be explicit or generic.
Here are two rules:
struct ValidationRuleLength: ValidationRule {
typealias InputType = String
//...
}
struct ValidationRuleCondition<T>: ValidationRule {
typealias InputType = T
// ...
}
Elsewhere, I have a function that validates an input with a collection of ValidationRules:
static func validate<R: ValidationRule>(input i: R.InputType, rules rs: [R]) -> ValidationResult {
let errors = rs.filter { !$0.validateInput(i) }.map { $0.failureMessage }
return errors.isEmpty ? .Valid : .Invalid(errors)
}
I thought this was going to work but the compiler disagrees.
In the following example, even though the input is a String, rule1's InputType is a String, and rule2s InputType is a String...
func testThatItCanEvaluateMultipleRules() {
let rule1 = ValidationRuleCondition<String>(failureMessage: "message1") { $0.characters.count > 0 }
let rule2 = ValidationRuleLength(min: 1, failureMessage: "message2")
let invalid = Validator.validate(input: "", rules: [rule1, rule2])
XCTAssertEqual(invalid, .Invalid(["message1", "message2"]))
}
... I'm getting extremely helpful error message:
_ is not convertible to ValidationRuleLength
which is cryptic but suggests that the types should be exactly equal?
So my question is... how do I append different types that all conform to a protocol with an associated type into a collection?
Unsure how to achieve what I'm attempting, or if it's even possible?
EDIT
Here's it is without context:
protocol Foo {
typealias FooType
func doSomething(thing: FooType)
}
class Bar<T>: Foo {
typealias FooType = T
func doSomething(thing: T) {
print(thing)
}
}
class Baz: Foo {
typealias FooType = String
func doSomething(thing: String) {
print(thing)
}
}
func doSomethingWithFoos<F: Foo>(thing: [F]) {
print(thing)
}
let bar = Bar<String>()
let baz = Baz()
let foos: [Foo] = [bar, baz]
doSomethingWithFoos(foos)
Here we get:
Protocol Foo can only be used as a generic constraint because it has
Self or associated type requirements.
I understand that. What I need to say is something like:
doSomethingWithFoos<F: Foo where F.FooType == F.FooType>(thing: [F]) {
}
Protocols with type aliases cannot be used this way. Swift doesn't have a way to talk directly about meta-types like ValidationRule or Array. You can only deal with instantiations like ValidationRule where... or Array<String>. With typealiases, there's no way to get there directly. So we have to get there indirectly with type erasure.
Swift has several type-erasers. AnySequence, AnyGenerator, AnyForwardIndex, etc. These are generic versions of protocols. We can build our own AnyValidationRule:
struct AnyValidationRule<InputType>: ValidationRule {
private let validator: (InputType) -> Bool
init<Base: ValidationRule where Base.InputType == InputType>(_ base: Base) {
validator = base.validate
}
func validate(input: InputType) -> Bool { return validator(input) }
}
The deep magic here is validator. It's possible that there's some other way to do type erasure without a closure, but that's the best way I know. (I also hate the fact that Swift cannot handle validate being a closure property. In Swift, property getters aren't proper methods. So you need the extra indirection layer of validator.)
With that in place, you can make the kinds of arrays you wanted:
let len = ValidationRuleLength()
len.validate("stuff")
let cond = ValidationRuleCondition<String>()
cond.validate("otherstuff")
let rules = [AnyValidationRule(len), AnyValidationRule(cond)]
let passed = rules.reduce(true) { $0 && $1.validate("combined") }
Note that type erasure doesn't throw away type safety. It just "erases" a layer of implementation detail. AnyValidationRule<String> is still different from AnyValidationRule<Int>, so this will fail:
let len = ValidationRuleLength()
let condInt = ValidationRuleCondition<Int>()
let badRules = [AnyValidationRule(len), AnyValidationRule(condInt)]
// error: type of expression is ambiguous without more context