DEV Community: Stoian Dan

How to populate your #Previews in SwiftUI

Stoian Dan — Fri, 05 Sep 2025 21:23:00 +0000

Apple created the #Preview macro to more easily preview your SwiftUI views in Xcode:

#Preview {
    BookView()
}

You can even write some handy code in a #Preview:

#Preview {
    let books = ["Eros&Agape, by Anders Nygren", "Commentary to Galatians, by Martin Luther"]

    BookView(books: books)
}

However, what do you do when you want to cache the data needed for preview initialization or, another use case, if you need to use async code to get that data in the first place?

While initially I saw approaches like:

#Preview {
    @Previewable @State var books: [Book]  = []

    if books.isEmpty {
        ProgressView()
          .task {
             books = await myAsyncFunc()
          }
    } else {
        BookView(books: books)
    }
}

This was a hacky way to do it and it also didn't provide caching. So here's the more Apple way — that I wish Apple would advertise more , as they're documentation doesn't really provide examples in general 😩 — to do it:

struct BookProvider: PreviewModifier {
    static func makeSharedContext() async -> [Book] {
             return await myAsyncBookGenerator()
    }


    func body(content: Content, context: [Book]) -> some View {
        BookView(books: context)
    }
}

In essence, you can use makeSharedContext to generate whatever type you want – by default it's Void, so you can also entirely omit this function – then, via the body method, you get your content (whatever the #Preview provides), your context (whatever makeSharedContext provides); finally you have your chance to return whatever the newly modified view! That's it!

To apply the modifier, just:

#Preview(traits: .modifier(BookProvider())) {
    BookView()
}

I'm just wondering whether or not Apple could have used generics (probably not? because you can't really do that in protocols…) to not have that Content type be a type erased view.

P.S.
I'll admit my use-case is a bit strange because I don't really make use of the content variable – I can't, because it's typed erased – I just directly return a view no matter what it's being thrown by the client #Preview.

How Combine works: Operators

Stoian Dan — Fri, 19 Jan 2024 21:15:27 +0000

In my previous post, I explained subscriptions and I want to focus now on operators.

As opposed to Subscription and Publisher operators don't have an interface of their own, they really are just publishers that subscribe to upstream publishers, receive the data from there, do something with it, and then send data to downstream publishers:

   Just(5)
    .map {$0 + 1}
    .map { $0 + 2 }
    .sink { print("we got \($0)") }

In this example, Just is our most upstream publisher, the two map publishers are what we call operators; the first one subscribes to Just adds 1 to that value and sends it downstream where another map once again, having subscribed to its upstream map publisher, adds 2 and sends the value downstream, this time to our end client, the sink subscriber.

So first, notice map as opposed to Just is not a type, but a method. Well, sort of.

To make it more convenient so that you don't have to creat a Map publisher yourself, Apple wrote map as an extension function that any publisher can have access to, something like:

extension Publisher {
    public func map<T>(_ transform: @escaping (Self.Output) -> T) -> Publishers.Map<Self, T>
}

Ok, so if Map returned by map is itself a Publisher that explains how downstream sink subscriber can subscribe to Map, right? It's a publisher, you can subscribe to it.

However, for me, the big question was, how did Map as a publisher, subscribe to its own upstream publisher?

Let's focus on this:

Just(5)
   .map {$0 + 1}

If map is only a publisher how does it subscribe to Just? Since it doesn't implement the Subscriber protocol?

The answer how this almost magic chain works is AnySubscriber. Quoting Apple documentation:

Use an AnySubscriber to wrap an existing subscriber whose details you don’t want to expose

To wrap an existing subscriber! Yes, it's also to hide implementation details or so, but what's most important is the following initializer AnySubscriber provides:

init(receiveSubscription: ((Subscription) -> Void)?, receiveValue: ((Input) -> Subscribers.Demand)?, receiveCompletion: ((Subscribers.Completion<Failure>) -> Void)?)

Creates a type-erasing subscriber that executes the provided closures.

In essence, what Map does is, once it receive its subscriber from downstream it wraps it in AnySubscriber and adds its logic, so that it can capture values from upstream and change them, when they are provided.

Imagine Maps receive<S>(subscriber: S) implementations as such:

    public func receive<S>(subscriber: S) where Output == S.Input, S : Subscriber, Upstream.Failure == S.Failure {
        let newSubscriber = AnySubscriber(receiveSubscription: { subscriber.receive(subscription: $0)},
                      receiveValue: { val in
                                         let newVal = // ... apply closure; add 1, in our caase
                                         subscriber.receive(newVal) },
                      receiveCompletion: { subscriber.receive(completion: $0) } )
        upstream.subscribe(newSubscriber)
    }

Map is wrapping the initial subscriber and then passing it forward, this allows it to capture data and transform it appropriately.

How Combine works: Subscriptions

Stoian Dan — Thu, 18 Jan 2024 22:10:17 +0000

In my previous post, I showed a basic, rudimentary Publisher and introduced elementary notions of Combine.framework.

If you want to find out how operators work, you can checkout my final post for the series.

Now, we will focus on Subscriptions. Normally, any decent publisher only starts sending values (well, often they don't do it directly, the subscription does it for them), only when it's requested. It honors that request, and after each time it sends a value, it checks to see if:

additional values are demanded or if none are demanded any longer
if the subscription has been canceled

That's what we will do today. For that we will write a Subscription class, I say class because as opposed to the publisher, this one gets passed around, so it makes sense to use a reference type.

The protocol Subscription:

protocol Subscription : Cancellable, CustomCombineIdentifierConvertible

demands of us:

func request(Subscribers.Demand)
func cancel()

Notice a subscription is cancelable, so it can be canceled at any time. This is why subscriptions need be stored somewhere once the subscriber has received it form the publisher. Because losing that reference, when it goes out of scope, Swift will automatically call cancel for us.

Also notice the request method. It gets called by the subscriber whenever he feels like. A subscriber should not receive values until he calls the request method with an initial demand. Subscribers.Demand can be:

none (.none) don't give me anything
unlimited (.unlimited) give me infinite values
max(Int?) give me a finite amount of values

That's when we can start sending values to our subscriber. And we should also honor the demand, not to go above requested values. Also, demand can be called multiple times by the subscriber, it's also our decision if we can honor all that those demands or not. But it's something we should keep in mind.

Here's our custom Subscriber:



 extension Until {
     public class Sub: Subscription {

        private var subscriber: AnySubscriber<Int,Never>?

        private var demand: Subscribers.Demand = .none


         private let endVal: Int


         func request(_ demand: Subscribers.Demand) {
             self.demand = demand
             // only send if there is demand
             if demand != .none {
                 startSending()
             }
        }

         public init<S>(_ subscriber: S, _ endVal: Int) where S : Subscriber, Never == S.Failure, Int == S.Input {
            self.subscriber = AnySubscriber(subscriber)
            self.endVal = endVal
        }


         private func startSending() {
             for value in (0...endVal) {
                 // make sure subscriber has not canceled
                 // or he's demand is lower that what the publisher told us
                 guard let subscriber,
                       self.demand <= value else {
                     return
                 }
              // after every receive call, the subscriber can ask for more, or less...
                let additonalDemanand = subscriber.receive(value)
                demand += additonalDemanand
            }
           // when done send the trigger event
             subscriber?.receive(completion: .finished)
        }

       // if the subscriber cancels, we honor that and terminate our reference to him
         func cancel() {
            subscriber = nil
        }

    }
}

In our publisher from the previous post, we can update the receive logic to:

    public func receive<S>(subscriber: S) where S : Subscriber, Never == S.Failure, Int == S.Input {
        let subscription = Until.Sub(subscriber, endValue)
        subscriber.receive(subscription: subscription)
    }

How Combine works: Publishers

Stoian Dan — Thu, 18 Jan 2024 21:53:19 +0000

Apple's Combine.framework provides support for async and reactive programming, and while Swift's latest async/await keywords make it easy to write code that reads linear, but is asynchronous, that's not a 100% overlap with Combine, hence, it's still relevant.

Combine is not all about async programming, but about reactive programming, about streaming data and reacting to change in data.

Basically, reactive programming is about reacting to changes in data, or to events. This is done via streams; channels that unite our data during all time and update us with any possible changes as they come.

Therefore, talking the above concepts into consideration, let's see how the map to the Combine API.

Combine defines:

Publisher - a protocol to which one ca subscribe to receive values over time
Subscriber - a client of a Publisher, that receives the values
Subscription the binding between a publisher and subscriber
Finally, there is the concept of an operator. Operators are just Publishers that act as intermediary between a upstream publisher and a downstream publishers or a terminal subscriber. They often transform/prepare data for the end subscriber. This allows for greater modularity as these operators can be reused, inserted or removed at will, thus creating an effective pipeline between the initial, upstream publisher and the end subscriber.

Let's say we want to create a Publisher that publishes all values from 0 to n, like a range, starting always from 0 and going until n. We'll call it Until.

A publisher doesn't necessarily directly create its own values. Publishers are often structs, i.e. value types, they can be created in place and aren't pass around. There is notable exception that is the Subject publisher.

The Publisher protocol is generic over two types, an Output, the type of data which it will yield, and a Failure, the type of error which it yields, should something go wrong:

protocol Publisher<Output, Failure>

Until will always yield Int values and there's no real good reason to encounter and error, so our Failure type will be Never.

Other than that the only required method a Publisher needs implement is called receive that receives a Subscriber, acknowledging it by providing back a subscription.

func receive<S>(subscriber: S) where S : Subscriber, Self.Failure == S.Failure, Self.Output == S.Input

This might look complicated, all it's really saying is that the method is generic every a subscriber type and that subscribes's expected input value type needs match our expect output type, so with the failure type, makes sense?

Let's implement this:

import Foundation
import Combine

struct Until: Publisher {
    // we output integers
    public typealias Output = Int
    // we never throw errors
    public typealias Failure = Never

    // the end value at which stop
    let endValue: Int


    public init(_ endValue: Int) {
        self.endValue = endValue
    }

    public func receive<S>(subscriber: S) where S : Subscriber, Never == S.Failure, Int == S.Input {
      // TODO: implement it
    }
}

Great! Now how do we create a subscription to give it back to our subscriber? I'll leave that for a next episode.
For now out publisher will be a bit violent. Normally, the subscriber receives values only after he initially demands them. After each value received, he can demand even more, or less, as he wishes.

For now, our publisher will generate his own values and send them to the subscriber, regardless if he wants or not, but in the next episode we will do this right:

    public func receive<S>(subscriber: S) where S : Subscriber, Never == S.Failure, Int == S.Input {
        // a dummy subscription that ignores demands
        let subscription = Subscriptions.empty
        subscriber.receive(subscription: subscription)

        // send the subscriber the value immediately
        // ignoring any of his possible demands
        for val in 0...endValue {
           let _ = subscriber.receive(val)
        }
        // tell our subscriber we are done
        subscriber.receive(completion: .finished)

    }

How do we use this? We will need a subscriber, lucky Apple made one called Sink, it automatically demands an unlimited amount of data and has a callback where we can use the data provided by the publisher:

// store the subscription provided by sync, 
// normally if we would not do this, it will cancel our request
var cancellables = Set<AnyCancellable>()

    Until(10).sink(receiveValue: { val in
        print("We received \(val) from publisher!")

    }).store(in: &cancellables)

Swift's POP (Protocol Oriented Programming) paradigm in rea life

Stoian Dan — Tue, 03 Jan 2023 14:19:43 +0000

Introduction

Imagine we want to implement a sort of postal system, where messages can be sent from someone to the post office; where it will be accordingly dispatched to the right destination.

Beginning

We could go ahead and define a simple data model, that represents a message.
This entity holds the actual message (we'll call it content), and some meta-data, i.e. data about the message itself.

Since we want this message to be immutable and we don't want shared references of it, we can make it a struct, as opposed to a class:

struct Message {
   // the meta-data; who is sending this message
   let sender: String
   // also meta-data; the receiver of the message
   let to: String 
   // the actual content of the message
   let content: String
}

The Dispatcher

Now that we have a data model, which will be a shared entity between sender (a person) and dispatcher (the postal office).
We can go ahead and imagine our dispatcher:

class Dispatcher {
    public func dispatch(_ message: Message) {
       print("Sending \(message.content) to \(message.to) from \(message.from)")
    }
}

The Sender

Finally let's imagine the person sending the message:

class Person {
     private unowned let dispatcher: Dispatcher
     let name: String
     init(dispatcher: Dispatcher, ) {
        self.dispatcher = dispatcher
        self.name = name
     }

     public func sendMessage(of message: Message) {
         dispacher.dispatch(message)
   }
}

Example

This looks ok. Let's see how it will look in practice:

    let dispatcher = Dispatcher()
    let helvidius = Person(dispatcher: dispatcher, name: "Helvidius")
    let jovinian = Person(dispatcher: dispatcher, name: "Jovinian")

   helvidius.sendMessage(of: Message(sender: helvidius.name, to: "Jovinian", content: "Hi Jovinian! How are you?"))

The actual problem

Notice however, it's a bit odd that Bob has to specify he's the sender.
A person has a name, and if a person sends a message, he's always going to be the sender.
In fact, the current code could be exploited, supposing we'd offer anyone the ability to send messages (i.e. Person class would be a public API):

    let dispatcher = Dispatcher()
    let evilMike = Person(dispatcher: dispatcher, name: "Evil Mike")    
   evilMike.sendMessage(of: Message(sender: "Andy", to: "Sandy", content: "Hi Sandy! I'm Andy, and I think you look ugly!"))

The solution!

Protocols could make our lives much more easy. To start, we've noticed every person has a name; it also s seems maybe not just persons can send messages. why not have machines be able to send messages as well? All we need after all, besides the content and receiver, is for the sender to identify himself.
We could use Swift's UUID type, and that would be a great idea! However, for the sake of simplicity, well stick to a name field, of type string:

protocol Sender {
   var name: String { get }
}

Great! Now we could have a ton of other types that can be senders, like machines:

class Machine: Sender {
   let name: String
   let dispacher: Dispatcher

   init(name: String, dispathcer: Dispathcer) {
       self.name = name
       self.dispathcer = dispatcher
   }

   public sendHappyNewYear() {
       let date = Date.now

       let components = Calendar.current.dateComponents([.month, .day], from: date)

         if components.day == 1 && components.month == 1 {
                dispatcher.dispatch(Message(sender: "Robot1", to: "Sandy", content: "Happy new Year Sandy!"))
         }

   }
}

However, the actual problem still remains, just about anyone can create a message and pretend to be someone else!
So here's where POP (Protocol Oriented Programming) comes more handy in place.

We can make the initializer (or constructor, if you will) of Message entity fileprivate!

struct Message {
   // the meta-data; who is sending this message
   let sender: String
   // also meta-data; the receiver of the message
   let to: String 
   // the actual content of the message
   let content: String

   fileprivate init(sender: String, to: String, content: String) {
      self.sender = sender
      self.to = to
      self.content = content
   }
}

Great, now we can define an extension method on the Sender protocol. That is a method that anyone who's a sender, can automatically benefit from, even retroactively! I.e. entities that already conform to the Sender protocol before the extension method is introduced can benefit from!:

struct Message {
   ...
}

extension Sender {
   func createMessage(to receiver: String, content message: Message) -> Message {
    Message(sender: self.name, to: receiver, content: message)
}
}

Now any sender can call the createMessage method, that will automatically use the name the Sender has, because remember, the only thing we know about a Sender is that he has a name, and we can make use of that name in protocol extensions.

Why Rust is a "modern" programming language

Stoian Dan — Sat, 26 Dec 2020 12:22:22 +0000

Introduction

Rust is a compiled, statically typed, multi-paradigm, modern programming language designed for memory safety and concurrency, without needing a garbage-collector.

What does "modern" mean?

Granted, I've used the word modern, precisely to capture attention. The term is subjective, and many of the features that I consider "modern" are actually concepts borrowed from other languages (more on that later).
However, it's the selection of features and the cargo ecosystem, providing support for dependency management, building, testing, etc., that make the language truly modern.

Statically typed

Let's start with the non-controversial. Being statically typed means data types are known at compile time.
Rust is trying to bring the compiler on your side, by catching as many problems as possible, before your program runs. Knowing data types at compile time allows it to do just that. But that doesn't mean the experience needs to be verbose:

let x : u32 = 10; // type explicitly declared as an unsigned 32-bit integer  
let y = x + 5; // y's type is also u32, but it's inferred by the compiler

Memory safety

Rust wants to make sure that you write correct programs.That won't dereference dangling (invalid) pointers, access uninitialized memory (more on this later). Similar to C++'s RAII when things pass out of scope, memory gets freed for you:

    use std::fs::File; // "import" from module responsible for file-system interaction
    {
     // grab a resource 
    let fileHandler = File::open("foo.txt")?; 
    //... do stuff with out file
    } // when fileHandler goes out of scope, memory is freed

What's also nice is that Rust won't allow you to reference names that are out of scope:

  fn add(first : u32, second : u32) -> &u32 {
      let result = frist + second;
      return &result; // error
  } // result gets freed here

result will get deallocated when execution get out of add's scope, so returning a reference (via & operator) to it is invalid. (this code would also require something called reference lifetimes, that won't be covered here.)

"Modern"

Here's my favorite part. As previously said, many of these features are inspired from other languages. Rust has been influenced by many languages, learning from their mistakes and not repeating them. It borrows features from functional programming, but the following selection makes it shine, providing support for a multi-paradigm development.

Destructuring

You might be familiar with this from JavaScript. Say we have a 3D point, Point3D:

//a so called "tuple struct"
// with three unsigned integers corresponding to x,y,z 3D axis
struct Point3D(u8,u8,u8);

We can retrieve only the information we are interested in, by destructuring

 let three_d = Point3D(4,6,3);
 let (x, y, _) = three_d;
 println!("The 2D cooridnates are x: {} and y: {}", x, y);

Pattern matching

This is just precious. Let's say you have a Person struct, described by name and age:

struct Person {
    name : String,
    age  : u8
}

With pattern matching you can do things you've always dreamed about with a traditional switch statement:

let p = Person { name : String::from("Jennifer"), age : 23 };

    match (p.name.as_ref(),p.age) { // match operator pattern matches the result, much like a switch statement, only more advanced
        ("Jennifer",_) => println!("Oh, Jenn it's you, I need help with the cake, dear."),
        (name,minor) if minor < 18 => println!("Dear {}, there's some RobbyBubble for you.", name),
        (name, major) if major >= 18 => println!("Dear {}, there's some champain for you.", name),
        _ => {} // default case
    }

If you noticed, here we also used tuple destructuring. At the match statement, where we created a tuple paired with a person's name and age.
Pattern matching is really powerful and has application in the language other than the match statement, like if let.

Immutability by default & shadowing

Variables in Rust are immutable by default. Their state is guaranteed not to change. A feature coming from functional programming, in
languages like Haskell or Racket.

C#/Java for example, don't have this feature. The problem with having objects mutable by default is that you have to make sure passing references won't mess up their internal state.
Immutability can prevent annoying debugging situations like asking yourself why suddenly that list is empty? Why that bool you could have sworn should be true is actually false. 😑

This is usually solved by good encapsulation, but that's not always possible. Especially when working with third party code that's not in your control.
Also, Rust has a neat feature called shadowing, allowing you to do something like:

 // mutable variable explicitly marked so with the "mut" keyword  
  let mut p = Person{name: String:from(""), age : 24};
  // read the name
  println!("Please enter your name: ");
  // pass mutable name to be read from stdin
  std::io::stdin().read_to_string(&mut p.name);
  let p = p; // "shadow" old p name, and redefine it as immutable
...

From the last statement, we know nothing will messes up the state of p, because from there on it's immutable. ✔

No null!

The null reference, or lack therefor of is another reason why I call Rust "modern". Tony Hoare called null reference, his

billion-dollar mistake

Rust simply doesn't have null or any similar keyword. It describes the absence of a value by an optional (see optional type). Achieving this via generics. For example:

  let can_have_number : Option<u32> = Option::Some(6);
  match can_have_number  {
         Some(x) => println!("We have the number: {}",x),
         None => println!("There is no number to print!")
 }

We can wrap any data of any type inside an option, obliging the user to handle both cases. When there is data, wrapped inside a Some, or when there isn't any. To better understand this, we'll talk about generics and enums.

First class enum support

If you've ever used an enum, you might be familiar with the C style enums.
But in Rust, besides serving as some symbol or integer value enums can have associated values with them.
The Option type you've seen earlier is an enum, that could be generically defined as:

enum Option<T> {
    Some(T),
    None
}

Option has two possible values Option::Some(T) and Option::None.
Some describes the presence of a value. None describes the lack therefor of.
Notice, for None, we have no value associated, it's sufficient to say: "there's nothing here". For Some however, we're not just saying "there is, there is something in here". We're also actually storing and providing the data.
Can you see how that is another use case for pattern matching?

Traits

Traits are like interfaces in Java/C#, they allow for polymorphism, by making structs implement functionality and being able to refer to a struct type, as an interface type.
They differ in that traits can be implemented on types you have no control over.

Imagine using a third-party JPEG library for your very own photo viewer application.
The program, already supports PNG's, Bitmaps and other formats, that use a trait named Photo. If only that JPEG library had also known about it!😑
Well guess what, in Rust you can implement the Photo trait upon the JPEG structure provided by the library!
You can even implement self written traits upon built-in Rust data types like u8, String, etc. ✔

Conclusions

Together with plenty of other features like borrowing, multi threading and lots of zero-cost abstractions, Rust is a free/open-source modern language.
Developed at Mozilla Foundation, it's enabling all kinds of software, from so called system-programming (embedded, kernel programming) to web apps, via Web Assembly.
If you're interested in learning Rust, I recommend the free Rust book.