Open dhavalshreyas opened 4 years ago
IIRC, they're in Samples
currently because we explicitly don't want them to be added as dependencies elsewhere — they're just guideposts to help others build their own containers. Outside of that, are we willing to take on the maintenance burden of these, given we use parallel implementations internally?
One of the suggestions @bencochran brought up internally was the option of us publishing the structs for these Screen
s (instead of both the struct and the UIViewController) and allowing folks to add the conformance to Screen
themselves (BYO view controller). That would at least let us close the gaps between these samples and our own internal versions.
I believe this is the approach we're currently using in kotlin.
A few container
Screen
that are currently inSamples
, would be better situated with an independent dependency. This will enable easy consumption of these common UI containers.Containers in
Samples
currently:AlertContainer
BackStackContainer
ModalContainer
Possible future additions:
TabBarScreen
#1098EquatableScreen
- AScreen
that updates it's rendering only if it's contents have changed.ViewControllerLifecycleObserverScreen
- AScreen
that has callbacks for some commonUIViewController
lifecycle events.Proposal
Move container
Screen
s fromSamples
toWorkflowUICommon
and addWorkflowUICommon.podspec
in root. PublishWorkflowUICommon.podspec
to Cocoapods.