UI rendering is becoming extremely convoluted and complicated

[joekrill]

Is there a plan to simplify how one should be rendering the various UIs? Or at least document it?

I've noticed it has gotten increasingly convoluted and complicated understanding when to render which nodes. And it's not documented anywhere, as far as I can tell. Unless you count the looking at the source code in the@ory/elements package - and even there it's not straight-forward at all:

Usually (but not always!) the default group should be included when filtering nodes. Same with "hidden" nodes. Sometimes submit and button nodes should be excluded. input and script nodes should always be included only when rendering the webauthn or totp groups. And there's just a ton of this sorts of nuances, it seems.

One of the main reasons to use Kratos is the "bring your own UI" aspect. But it's becoming kind of absurdly complicated to even do that.

Is this documented somewhere that I just haven't found? Is there a plan to simplify all this without having to use @ory/elements?

[aeneasr]

hey @joekrill - thank you for the feedback and we agree that there are some implicit implications in the node UIs. What would be great would be to collect all the inconsistencies/discrepancies here or in an issue to figure out what to do (document, improve, fix, ...). As the complexity of the project is increasing day-by-day, it's also for us challenging to keep track of all the (implicit) api contracts we have.

[joekrill]

Thanks so much for the quick reply!

As the complexity of the project is increasing day-by-day, it's also for us challenging to keep track of all the (implicit) api contracts we have.

IMHO, there just shouldn't be any implicit contracts to keep track of in the first place. That's really the whole problem. Any contracts should be explicit in the response.

I think -- ideally -- the flow should include all necessary information needed to render the UI, without any complicated rules needed on the rendering side of things, at all. I suspect that has always been the intention, and that things just unintentionally devolved a bit. Maybe the structure of the response needs to be reworked?

I don't have a lot of in-depth knowledge of the project, so my observations/opinions may be misguided, but I'll share them anyway in the off chance they are useful.

As far as I can tell (based on the @ory/elements code) there's a few key reasons all this additional logic is needed in the first place:

1. Certain nodes should not be rendered based on some user state (i.e. "the current flow is a two factor flow if the user is logged in and has any of the second factor methods enabled."
2. The UI should be rendered as multiple separate forms.
3. There is a desire to customize the order/grouping of the form components.

For (1), I don't see why those nodes should even be returned in the first place. The backend has all this information already. It should know if the user is logged in. It should know if any second factor methods are enabled. It should certainly know the flow type it's returning. Those are some of the conditions currently being checked manually by @ory/elements, but the backend knows all those and so it should know whether or not to even return those nodes in the first place.

For (2), the response could be reworked to explicitly return those form groups instead of just relying on using the group property and implicit rules.

Something like this would provide some backward compatibility and be more explicit:

{
  ui: {
    nodes: [/*...nodes go here -- ensure each has a unique ID...*/],
    forms: [
      { 
         id: "oidc",
         nodes: [/* a list of node IDs to include. Or just inline the nodes here instead, even if it means duplicating them */], 
         messages: [],
      }, 
      { 
         id: "totp",
         nodes: [/*...*/],
         messages: [],
      },
    ]
  }
}

(3) will still have to be left to the rendering, but if the node groups are more explicit it becomes a purely cosmetic/ordering issue. It won't be necessary to break things up manually and figure out what other hidden fields need to be included, etc.

Like I said, I don't have a lot of in-depth knowledge of the project, and I haven't spent a ton of time thinking about all this, so I'm sure things are a lot more complicated than I've made them out to be. But I don't see how "bring your own UI" can be a realistic feature without removing all of those implicit rules.