You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's common that different settings connect to different models (in an applications where users have more to do) or that some things like changing your password/email have their own workflow for confirmation/verification.
So rather than using a single <form>, I usually to build a more modular settings menu.
For example, the user settings in LiNT are layed out like this:
My point is not about aesthetics, but the idea is to divide the page into several sections that can function as stand-alone components and use their own <form> (if applicable). For example, the change password option folds out into an old password / new password / repeat new password<form> that has its own submit event. This makes sense because (both here and in LiNT), changing your password connects to a different API endpoint from other settings.
Another advantage of dividing settings into several sub-components is that it's a component that can really grow out of control otherwise.
In this case, it would make sense to divide this page into the following sections:
This refactor should also include the /password/change/ endpoint to allow for easy password changes (rather than requesting a password reset link), although that could still be valid as an alternative.
It's common that different settings connect to different models (in an applications where users have more to do) or that some things like changing your password/email have their own workflow for confirmation/verification.
So rather than using a single
<form>
, I usually to build a more modular settings menu.For example, the user settings in LiNT are layed out like this:
My point is not about aesthetics, but the idea is to divide the page into several sections that can function as stand-alone components and use their own
<form>
(if applicable). For example, the change password option folds out into an old password / new password / repeat new password<form>
that has its own submit event. This makes sense because (both here and in LiNT), changing your password connects to a different API endpoint from other settings.Another advantage of dividing settings into several sub-components is that it's a component that can really grow out of control otherwise.
In this case, it would make sense to divide this page into the following sections:
Originally posted by @lukavdplas in #64 (comment)
The text was updated successfully, but these errors were encountered: