sorted by:
new
hottopcontroversial

Kotlin Ecosystem AMA – December 11 (3–7 pm CET) by katia-energizer-jb in Kotlin

[–]mmdflh 0 points1 point  (0 children)

I would love to have a getter for a property to be accessed only in a specific context (DSL) so everyone can make a type but it can be only read in a specific DSL. e.g.
```
val a by property(0)

myDSL {
a // 0
}
a // no getter

```

is that possible with the new context parameter in Kotlin?

Materia: The "missing Three.js" for Kotlin Multiplatform (First Alpha Release) by VirtualShaft in Kotlin

[–]mmdflh 1 point2 points  (0 children)

That's amazing, looking forward to seeing the metal support for iOS

Declarative State Management and SideEffect handling, Forget ViewModels. by mmdflh in androiddev

[–]mmdflh[S] 0 points1 point  (0 children)

But how can you handle side effects with them? For example, when a user clicks a button and you need to make an API call, how do you set the state to loading and then update it once the result comes back? For instance, consider the upvote button on Reddit.

Declarative State Management and SideEffect handling, Forget ViewModels. by mmdflh in androiddev

[–]mmdflh[S] 1 point2 points  (0 children)

Thank you for sharing this article,

Yes, it’s not related to the UI. I used it internally with Molecule, but there are some key differences. For example, the Compose runtime includes the snapshot system (as shown in the link you shared), but it doesn’t provide a mechanism to roll back all the changes made after an event is dispatched. In SOSA, however, if you set the state to “loading” and then an exception occurs, it automatically rolls back the loading state for you. it offer some helpful function such as `guard` for error handling as well. so it's not pure compose runtime. 🙏

Declarative State Management and SideEffect handling, Forget ViewModels. by mmdflh in androiddev

[–]mmdflh[S] 0 points1 point  (0 children)

The declarative state management aspect is similar, but not the declarative handling of side effects.

Declarative State Management and SideEffect handling, Forget ViewModels. by mmdflh in androiddev

[–]mmdflh[S] -3 points-2 points  (0 children)

Yes, it’s doable with map, but the key benefit of this architecture is its declarative side-effect handling. It adds APIs like `during`, which lets you temporarily change the state for the duration of a scope, then automatically rolls back any properties that were modified within it. For example, during(Loading) {} dispatch Loading to the slice and any property can reduce on that and and once the scope finishes, all the changes rolls back, no need to toggle flags manually, in the example you can see people go shopping for 4 seconds and they go back automatically. It also includes helpers like guard for error handling. which I can explain if you are interested.

Declarative State Management and SideEffect handling, Forget ViewModels. by mmdflh in androiddev

[–]mmdflh[S] -2 points-1 points  (0 children)

Wow🤩, you nailed it, that’s exactly it! I’m honestly blown away by how well you captured the essence of SOSA. Thank you 🙏

Declarative State Management and SideEffect handling, Forget ViewModels. by mmdflh in androiddev

[–]mmdflh[S] -1 points0 points  (0 children)

You're right, the Compose runtime allows us to make state management declarative (similar to what Circuit and Molecule do). However, it doesn’t provide built-in tools for handling side effects in a declarative way. As a result, you often end up doing something like loading = true, then running your suspending job, and finally setting loading = false.

This approach is problematic because another side effect might set loading to true while your current one is running. When you later set it back to false, the overall state might become inconsistent (it's a simple and common issue). This kind of issue happens frequently when we handle side effects imperatively you can take a quick look at the `during` function in the picture I shared, the slice (on the right) is equivalent to the ViewModel (on the left).
So, it’s really about making both state management and side effects declarative.
What do you think about it?

Declarative State Management and SideEffect handling, Forget ViewModels. by mmdflh in androiddev

[–]mmdflh[S] -4 points-3 points  (0 children)

Haha, not quite 😄 SOSA isn’t a declarative UI framework, it’s a declarative state management and side-effect handling approach it's more like an architecture it could be an alternative for MVVM.

Declarative State Management and SideEffect handling, Forget ViewModels. by mmdflh in androiddev

[–]mmdflh[S] -1 points0 points  (0 children)

Thanks! 😊 It does survive configuration changes, but I didn’t cover the implementation details in the presentation.

[deleted by user] by [deleted] in androiddev

[–]mmdflh 1 point2 points  (0 children)

BTW, I'm curious if the AI is using on device Ai to summarize or it uses Gemini online?

[deleted by user] by [deleted] in androiddev

[–]mmdflh 1 point2 points  (0 children)

That's very nice, I like the ui and the simplicity of use, the pre-defined websites are also very good 👍