Extracting PhxForm and PhxSubmitButton to their own library

[bcardarella]

I'd like to get PhxForm and PhxSubmitButton extracted out into a library. These two views are not part of SwiftUI but enable necessary behavior for building LiveView Native apps.

These should be extracted into a new library: liveview-native-swiftui-form

[AZholtkevych]

Brian have to make repository for LVN team

[bcardarella]

Done: https://github.com/liveviewnative/liveview-native-swiftui-form

[AZholtkevych]

Thanks a lot, FYI @carson-katri @shadowfacts @supernintendo

[bcardarella]

@AZholtkevych this job isn't completed, just that the repo was created. The work of extracting still needs to happen.

[AZholtkevych]

Yes, that's why I've reopened. Closed accidentially

[carson-katri]

Would we need a way of specifying multiple registries for this to be extracted?

[shadowfacts]

Yes, my plan is to have a registry type to let you compose registries that looks something like:

struct MultiRegistry<First: CustomRegistry, Second: CustomRegistry>: CustomRegistry {
    enum TagName {
        case first(First.TagName)
        case second(Second.TagName)
        init?(rawValue: String) {
            if let name = First.TagName(rawValue: rawValue) {
                self = .first(name)
            } ...
        }
    }

    static func lookup(_ tag: TagName, ...) -> some View {
        switch tag {
            case .first(let name):
                First.lookup(name, ...)
            ...
        }
    }
}

[carson-katri]

That's a good solution. If I'm imagining its use right, you may want to consider including a simpler form of creating it. Nesting them could get fairly clunky when you have many addon packages:

MultiRegistry<
  MyAppRegistry,
  MultiRegistry<
    FormRegistry,
    MultiRegistry<
      ChartsRegistry,
      AVKitRegistry
    >
  >
>

Maybe providing something like this?

struct MyAggregateRegistry: AggregateRegistry {
  static var registries: some CustomRegistry.Type {
    MyAppRegistry.self
    FormRegistry.self
    ChartsRegistry.self
    AVKitRegistry.self
  }
}

Which would get built out to the MultiRegistry.

[bcardarella]

I've renamed the repo to live-form to help differentiate it from form in SwiftUI

I believe the view should follow, so instead of phx-form we should have live-form and instead of phx-button there is live-button

I'm open to namespace suggestions instead of live if there is any better ones?

[supernintendo]

@bcardarella Will this library provide live form functionality for other platforms as well or only iOS? WIth that naming I could see it being conflated as a cross-platform library rather than something that only works with the SwiftUI client.

[bcardarella]

@supernintendo the name of the actual repo is liveview-native-swiftui-live-form

I don't know yet it if this will be necessary on other platforms or not. Our only reason for this on SwiftUI is because there is no way to encapsulate child inputs within a form and serialize them. Also there is no way to associate a Button with a Form in SwiftUI. We want this behavior to make writing forms in LVN easier. I'll have to investigate if other platforms provide this or we will have to reproduce this.

In the event that we have to reproduce it I think we should rename the repo to:

liveview-native-live-form

and include all target platforms along with platform specific supporting Elixir code.

[AZholtkevych]

From @bcardarella @Kashif-E does Jetpack compose allow for automatic serialization of all child inputs inside of a form and associate submit buttons with the parent form similar to the web or do you have to wire all this up yourself like in SwiftUI? Knowing that will help us with this issue

[Kashif-E]

@bcardarella @AZholtkevych its the same as in swift ui

[bcardarella]

ok in that case I've updated the repo name to: liveview-native-live-form. The repo's structure should follow what I've outlined here: https://github.com/liveviewnative/liveview-client-swiftui/issues/173#issuecomment-1425906303