Hey All! <@UQY62FZU3> and I are excited to share o...
# feed
s
Hey All! @Mark Rebhan and I are excited to share our journey with KMP at Philo in a series of blog posts. We posted the first one today! We’ll be going into some technical depth about how we’ve been migrating Philo to a set of libraries for sharing business logic using KMP. https://blog.philo.com/kotlin-multiplatform-at-philo/ Thread in Slack Conversation
👌 1
👀 2
K 2
❤️ 1
Hey again! We just dropped another blog post specifically focusing on some of the challenges we faced and how we overcame them. We hope to follow up with another one soon! https://blog.philo.com/kotlin-multiplatform-at-philo-bumps-in-the-road/
e
List
is indexed by a
Long
,
that doesn't sound right… `List`s are
Int
-sized and indexed
s
hmm. Our experience was that in the compiled JS Longs were being constructed in the iterator.
s
Wow, you’re right. I just dusted off the reproducer we had (from 2 years ago!) and it is okio that is indexing using longs. I just tweaked the post.
e
ah that makes more sense
p
One thing I noticed is that many people struggle with KMP because they want to share the ViewModel. Perhaps if you only share the use cases and the whole data layer the integration is not too terrible. That way you skip all the flow and generics bridging. Which is the nightmare no one wants to live with. Some time ago a colleague did a presentation in my company about KMP + swiftui, the feedback from iOS folks, was that they like to write their ViewModels and KMP would be a hurdle bc usually they iterate a lot over the ViewModels code. And waiting for the Android team to do this would kill it. We then realized it is true, shared code should be code that doesn't change too often. So perhaps leaving the ViewModel native and KMP for domain and data is a better and faster experience. In fact, as per CLEAN, ViewModel belongs to the presentation or UI layer, and that you want it native.
s
Yeah, I think our post sort of glosses over that a bit. In reality, it isn’t the view model that we share, but something closer to the use-case. We leave any UI logic (eg what section of the page is showing, what item is focused, where is scroll) up to the client to track. There are, of course, tons of gray areas, and we do funnel most interactions through common code, even if they could be handled purely on the client side because it makes analytics much easier to standardize.
💡 1