Jesly Varghese

@jesly
17 Followers
294 Following
37 Posts
Mostly Swift & iOS things!!

I am having a hard time wrapping my head around MVVM with SwiftUI.

Whenever I use it, things feel wrong and hack-y. Unlike with UIKit.

In MVVM + SwiftUI, who owns the state ? Is it the ViewModel ? And who owns the ViewModel, the @State container ?
And how do you control the life time of your ViewModels ?

Feels like I am probably missing some good ideas around why it’s popular (other than an intermediate phase when codebases are migrating from UIKit).

Here's a neat trick with `async let` I didn't realize. You can use it to avoid blocking on synchronous work.

Any experienced programmer worth their salt will tell you that •producing• code — learning syntax, finding examples, combining them, adding behaviors, adding complexity — is the •easy• part of programming.

The hard part: “How can it break? How will it surprise us? How will it change? Does it •really• accomplish our goal? What •is• our goal? Are we all even imagining the same goal? Do we understand each other? Will the next person to work on this understand it? Should we even build this?”

“Building engineering” https://werd.io/2024/building-engineering
Building engineering

How I'm thinking about building an engineering culture.

Werd I/O

@jaredsinclair Great post! Small clarification on explicit view identity: the .id() modifier acts in *addition* to the structural identity defined by the view’s position in the view hierarchy. So .id() can never make two non-identical views identical, only the other way around. These two views have different identity despite having the same .id():

if flag {
MyView().id("one")
} else {
MyView().id("one")
}

Be Careful When you Initialize a StateObject Property Wrapper — https://jaredsinclair.com/2024/03/14/state-object-autoclosure.html

There’s an easy pitfall to fall into, and it can totally undermine the reason you're using StateObject in the first place.

Jared Sinclair | Be Careful When You Initialize a State Object

📝 New blog post on LMNT: “Lack of Vision” https://lmnt.me/blog/lack-of-vision.html
Lack of Vision

@nicklockwood @rhysmorgan Yeah it’s not the same, just similar.

But just wait until this proposal is accepted. They will become super powerful and I bet will be commonly used

https://forums.swift.org/t/pitch-inheriting-the-callers-actor-isolation/68391

[Pitch] Inheriting the caller's actor isolation

Hi. One problem we've been seeing with Swift concurrency is that there isn't an easy way for async functions to polymorphically share their callers' actor isolation. This makes it hard to use certain kinds of async abstractions from isolated contexts because technically the async functions in the abstraction have a different isolation, which means e.g. you can't share non-Sendable values with them. It also can have unwanted performance consequences. I've written a proposal which adds a handf...

Swift Forums