@Published: ano ito, prinsipyo ng paggana at aplikasyon

Ano ang @Published?

@Published — ay isang property wrapper na tinukoy sa modyul na Combine na nagdaragdag sa property ng klase ng kakayahang awtomatikong ipaalam sa mga subscriber ang tungkol sa mga pagbabago. Maaari lamang itong ilapat sa loob ng isang klase (hindi sa isang struct) at sa mga property lamang ng isang klase na sumusunod sa protocol na ObservableObject.

Kapag nagbago ang halaga ng isang @Published property, ang Combine ay bumubuo ng isang kaganapan sa pamamagitan ng built-in na publisher, na maa-access sa pamamagitan ng dollar prefix: $propertyName. Ang publisher na ito ay ObservableObjectPublisher, na pag-aari ng ObservableObject mismo. Awtomatikong nag-subscribe ang SwiftUI dito kapag ang view ay gumagamit ng @ObservedObject o @StateObject, at muling iginuguhit ang view sa bawat pagbabago ng anumang @Published property sa loob ng bagay.

Ayon sa aklat ni Matt Neuburg na „IOS 18 Programming Fundamentals with Swift” (2025), ang @Published ay isang maginhawang wrapper sa ibabaw ng pattern na willSet, na awtomatikong tumatawag ng objectWillChange.send(). Sa katunayan, binubuksan ng compiler ang @Published sa isang computed property na may willSet observer, na nagbibigay ng zero overhead sa runtime kumpara sa manu-manong implementasyon.

Gamitin ang @Published para sa lahat ng ObservableObject property na ang mga pagbabago ay dapat maipakita sa interface. Para sa mga property na hindi nakakaapekto sa UI, ang mga ordinaryong stored properties na walang @Published ay nagbabawas ng bilang ng mga hindi kinakailangang muling pagguhit.

Paano Gumagana ang @Published

@Published ay bumubuo ng dalawang pangunahing elemento sa panahon ng kompilasyon. Una — isang nakaimbak na property na may willSet observer na tumatawag ng objectWillChange.send() bago isulat ang bagong halaga. Pangalawa — ang projection na $propertyName na nagbabalik ng Published.Publisher na maaaring gamitin nang direkta sa mga pipeline ng Combine.

Isaalang-alang ang klase na Settings na may tatlong property: dalawang @Published at isang ordinaryo:

class Settings: ObservableObject {
    @Published var username: String = "Guest"
    @Published var isDarkMode = false
    var lastLogin: Date = Date()  // walang @Published
}

Kapag nagbago ang username o isDarkMode, muling iginuguhit ng SwiftUI ang lahat ng view na naka-subscribe sa instance ng Settings. Ang pagbabago ng lastLogin ay hindi magti-trigger ng muling pagguhit. Kung kailangan mong manu-manong ipaalam sa mga subscriber ang tungkol sa pagbabago ng isang ordinaryong property, maaari mong tawagan ang objectWillChange.send() sa willSet observer.

Isang mahalagang detalye: @Published ay nag-publish lamang ng mga pagbabago sa direktang pagsulat sa property. Kung ang property ay isang reference type (klase) at ang panloob na estado nito ay nagbabago nang hindi pinapalitan ang reference, hindi ito makikita ng @Published. Sa ganitong mga kaso, kinakailangan ang manu-manong pagpapadala ng kaganapan o pagpapalit ng value type (struct).

@Published at Combine

@Published ay malapit na isinama sa Combine — bawat @Published property ay awtomatikong nagbibigay ng publisher na maa-access sa pamamagitan ng projection na $propertyName. Ito ay nagpapahintulot sa paglalapat ng mga operator ng Combine para sa pagsasala, pagbabago, pagsasama-sama, at naantalang pagproseso ng mga halaga.

Isang tipikal na senaryo — paghahanap na may debounce. Ang input field ay nakatali sa @Published property na searchText, ngunit ang kahilingan sa server ay dapat ipadala lamang pagkatapos ng 300 ms na pause. Ang Combine na may $searchText.debounce ay nilulutas ito sa isang linya:

class SearchViewModel: ObservableObject {
    @Published var searchText = ""
    @Published var results: [String] = []
    private var cancellables = Set<AnyCancellable>()

    init() {
        setupSearchSubscription()
    }

    private func setupSearchSubscription() {
        $searchText
            .debounce(for: .milliseconds(300), scheduler: RunLoop.main)
            .removeDuplicates()
            .sink { [weak self] text in
                self?.performSearch(text)
            }
            .store(in: &cancellables)
    }

    private func performSearch(_ text: String) { }
}

Ayon sa artikulo ni John Sundell (Swift by Sundell, 2024), ang pagsasama ng @Published sa Combine ay isang karaniwang pattern para sa mga reaktibong pipeline sa mga aplikasyon ng SwiftUI: validation, debounce, throttle, combineLatest, merge sa iba pang mga publisher. Ang @Published ay nagsisilbing tulay sa pagitan ng imperatibong UI code at reaktibong Combine.

@Published vs Macro na @Observable

Sa paglabas ng iOS 17, ipinakilala ng Apple ang macro na @Observable, na nag-aalok ng alternatibong diskarte sa reaktibidad nang walang ObservableObject at @Published. Ang @Observable ay awtomatikong sumusubaybay sa pag-access sa mga property sa antas ng pagbasa, hindi pagsulat, na nagbibigay ng mas tumpak na mga muling pagguhit — tanging ang view na nagbabasa ng partikular na binagong property ang naa-update.

Ngunit hindi ito nangangahulugan na ang @Published ay luma na. Ang @Published ay nananatiling kinakailangan kapag kailangan ang integrasyon sa mga pipeline ng Combine — ang projection na $propertyName ay nagbibigay ng publisher na wala sa @Observable. Bukod pa rito, para sa backward compatibility sa iOS 16 at mas luma, ang @Published+ObservableObject ay ang tanging pagpipilian. Ayon sa sesyon ng Apple WWDC 2023 na „Discover Observation in SwiftUI”, inirerekomenda ng Apple ang @Observable para sa mga bagong proyekto, ngunit tahasang pinapanatili ang suporta para sa @Published para sa umiiral na code at mga senaryo ng Combine.

Sa praktika, maraming proyekto ang gumagamit ng hybrid na diskarte: ang mga bagong modelo ng data ay isinusulat gamit ang @Observable, habang ang umiiral na ObservableObject na may @Published ay nananatili nang walang refactoring. Ang @Published ay hindi rin mapapalitan kapag kinakailangan ang tumpak na kontrol sa pag-publish — halimbawa, pag-antala ng abiso hanggang sa pagkumpleto ng batch update ng maraming property.

Mga Karaniwang Pagkakamali sa @Published

Unang pagkakamali — paglalapat ng @Published sa isang struct. Ang compiler ay magpapakita ng error: „Property wrapper cannot be applied to a computed property” o „'@Published' is only available on members of a class”. Ang @Published ay nangangailangan ng referential semantics, dahil ang ObservableObjectPublisher ay isang klase na dapat ay natatangi para sa bawat instance.

Pangalawang pagkakamali — pagbabago ng nilalaman ng isang reference property nang hindi pinapalitan ang reference. Kung ang @Published property ay may uri na array na [String] at tinawag mo ang array.append("new"), hindi makikita ng @Published ang pagbabago dahil hindi nagbago ang reference sa array. Solusyon: magtalaga ng bagong halaga sa property na array = array + ["new"] o gamitin ang objectWillChange.send() nang manu-mano.

Pangatlong pagkakamali — labis na bilang ng mga @Published property. Bawat @Published property ay nagti-trigger ng muling pagguhit ng lahat ng view na naka-subscribe sa ObservableObject, hindi lamang ng mga nagbabasa ng property na ito. Ayon sa Point-Free (2025), ang paghahati ng isang malaking ObservableObject sa maraming maliliit na may @StateObject at @EnvironmentObject ay nagbabawas ng bilang ng mga hindi kinakailangang muling pagguhit at nagpapabuti ng pagganap.

Mga Halimbawa ng Kodigo

Unang halimbawa — ViewModel ng form ng pagpaparehistro na may validasyon. Ang mga @Published property na email at password ay nagti-trigger ng pagpapakita ng mga error sa validasyon sa pamamagitan ng pipeline ng Combine:

class RegistrationViewModel: ObservableObject {
    @Published var email = ""
    @Published var password = ""
    @Published var emailError: String?
    @Published var isFormValid = false
    private var cancellables = Set<AnyCancellable>()

    init() {
        $email
            .map { $0.contains("@") ? nil : "Invalid email" }
            .assign(to: &$emailError)
            .store(in: &cancellables)

        $email.combineLatest($password)
            .map { !$0.isEmpty && !$1.isEmpty }
            .assign(to: &$isFormValid)
            .store(in: &cancellables)
    }
}

Pangalawang halimbawa — manu-manong pag-publish para sa isang koleksyon ng mga reference na elemento. Sa halip na palitan ang buong array sa bawat pagbabago sa loob ng isang elemento, ginagamit ang objectWillChange.send():

class TodoItem {
    var title: String
    var isDone = false
    init(title: String) { self.title = title }
}

class TodoListViewModel: ObservableObject {
    @Published var items: [TodoItem] = []

    func toggle(item: TodoItem) {
        item.isDone.toggle()
        self.objectWillChange.send()  // manu-manong abiso
    }
}

Pangatlong halimbawa — Assign sa isang @Published property sa pamamagitan ng Combine. Gamit ang bagong syntax ng Swift 5.9, maaaring direktang magtalaga sa pamamagitan ng projection na assign(to: &$property) nang walang Optional wrapper. Ito ang pinakamaikling paraan upang ikonekta ang isang publisher sa isang @Published property nang hindi lumilikha ng subscription.