Sometimes they transform those inputs into data; sometimes they perform I/O.
Conversation
Everything Is A Signal™
2
2
I… I don't think that's helpful in this discussion. ;)
1
I think it’s relevant, because it parallels some other conversations that we’ve had. We use signals to encapsulate effects.
1
It bucks the conventional understanding of how signals might be used, but it means that we don’t need this distinction.
1
Our view models are a collection of inputs and outputs. Some of which are effectful. All of which are signals.
1
What does it mean for an output to be effectful?
1
e.g., resulting in the presentation of a new view controller, or the view model beginning a network request.
1
OK. How do you express those effects as outputs in the interface?
1
My point is exactly that _you don’t need to_. Why is it important? The effects are an implementation detail.
2
Replying to
Trying to figure out how this is different from any object which performs effects when it e.g. receives a message.
Replying to
Is the significant point that all endpoints are expressed via signal APIs rather than via methods?
1
Yes. Everything can be treated as a functional series of inputs to outputs. Embedded effects are encapsulated away.
2
1
Show replies
Replying to
My remaining concern is: most of most view models are totally pure. Why not isolate the impurities?
1
That isolation is an implementation detail (but maybe could still be valuable), because the signal interface isolates it.
1
Show replies

