Hi folks! I'm wondering how many teams are using t...
# talk-kratos
b
Hi folks! I'm wondering how many teams are using the “ui” object returned by the kratos flow initialization APIs to dynamically render a form for the user at runtime, vs explicitly defining the form in your UI to match your identity schema? Dynamically rendering the form adds complexity and ambiguity to the UI since it's not known until runtime, but manually defining it makes it harder to change your identity schema since you also need to update your UIs. I'm experimenting with kratos and keen to hear from anyone who's tried either approach.
h
Probably comes down to preference in the end 😅
I’d say it’s easier to have a fixed form and update both pieces when you do (as it doesn’t happen often) than it is to have a dynamic form
👍 1
if you have many clients that render these forms the balance probably shifts
e
We started with a dynamic form on our site and app but we quickly moved the app to a static form and we'll probably do the same on the site as it lets you avoid a wait time before the form can be rendered
👍 1
b
Thanks for the responses. I think I'll start with a static form based on my identity schema for now. I think @high-optician-2097 you're right, it won't change often which reduces the risk a fair bit. Will update if it ends up coming back to haunt me!