TabView about liveview-client-swiftui HOT 12 CLOSED

What is the iOS target version? New navigation API was introduced in iOS 16, I'm wondering if that can be leaned on or not.

Once iOS 16 is officially out (Monday, September 12th), we'll be targeting that as the baseline. The iOS 16 navigation API is already used when it's available, and the iOS 15 navigation implementation will be dropped once the deployment target is updated.

from liveview-client-swiftui.

I think we have the benefit of seeing what React Native has done and steal what works but deviate where it doesn't make sense. The programming model we need to focus on is: "can a junior dev build a native app with LiveView" so app implementations in this library will need to focus on being as super simple as possible. This will require more work to achieve but it gives us a good base to build more complex abstractions on top of. Keeping the barrier of entry low ensures that adoption can be optimized.

from liveview-client-swiftui.

@kgautreaux I don't think we'll have a good sense on this until we start building apps and formalize the API

from liveview-client-swiftui.

@BryanJBryce I can bring that up on our weekly call today, but I believe we are looking forward to 16 for sure. If it means we can drop a ton of stuff form 15 then I'm OK dropping 15 support entirely as we are still aways out to being production ready. We might as well align on the latest API.

from liveview-client-swiftui.

I think not navigating from the server is a good non-goal. Navigation is almost always done by user input anyway and would be akin to hitting a new url on the web.

from liveview-client-swiftui.

If philosophically and conceptually @State is going to be treated like assigns then the idiomatic SwiftUI way to do it would appear to be the latter with a MainTabViewLive coordinating liveview rendering the top-level TabView and hierarchy.

In this scenario it seems like you could change assigns.selected in a handle_info callback if you wanted to navigate programmatically without user control.

More broadly patterning navigation after ReactNavigation with an App -> Screens -> Component hierarchy might work, though I do not know if this would paint the project into a corner for multi-window SwiftUI apps where Window -> Scene -> View seems to be the convention.

I'm sure it is harder than I think and we don't want to paint into a corner for things like cross-liveview animations.

from liveview-client-swiftui.

Concur. So then I have a follow-up question. Where do we think the pit of success lies for our target junior dev? Presumably they know elixir and liveview and want to make an app. Probably not an iOS dev who is just looking for state management that isn't RxSwift or Combine? I'm interested in who you see as the sub-market of junior devs?

from liveview-client-swiftui.

@kgautreaux I'd assume Elixir/Phoenix 101 knowledge and SwiftUI 101 knowledge. So the initial starting point for a junior's thought process might be. I know how to do this in LiveView and I know how to do that in SwiftUI, how do I do it in LiveView Native? And the smaller the leap that is from a basic understanding of the two underlying technologies the better.

from liveview-client-swiftui.

@bcardarella What is the iOS target version? New navigation API was introduced in iOS 16, I'm wondering if that can be leaned on or not.

from liveview-client-swiftui.

@BryanJBryce that's a good way to explain it. I wouldn't expect someone with zero knowledge in either tech to know what to do. But someone with a bit of training should be able to build something.

from liveview-client-swiftui.

@bcardarella Only a couple devices have been dropped since iOS 13 so it is not like it's a big user experience sacrifice and it is a huge win for getting a new project up and running.

from liveview-client-swiftui.

Closed in favor of #249

from liveview-client-swiftui.