Skip to content

[SignInPage] Remove docs context from component logic#4489

Merged
bharatkashyap merged 8 commits intomui:masterfrom
bharatkashyap:core/remove-docs-context
Dec 6, 2024
Merged

[SignInPage] Remove docs context from component logic#4489
bharatkashyap merged 8 commits intomui:masterfrom
bharatkashyap:core/remove-docs-context

Conversation

@bharatkashyap
Copy link
Collaborator

@bharatkashyap bharatkashyap commented Nov 28, 2024

  • From [SignInPage] Allow slotProps to override all labels #4418 (comment)
  • Removed two instances of checking if the component is being used inside the docs
  • Autofocus issue solved via adding a slotProp of autoFocus: false to each docs demo and removed handling it inside the component
  • Conditionally setting the loading state of the Sign In Button on deeper analysis does not appear to be required at all really, simply removed

@bharatkashyap bharatkashyap added internal Behind-the-scenes enhancement. Formerly called “core”. component: sign-in labels Nov 28, 2024
setFormStatus((prev) => ({
...prev,
loading: oauthResponse?.error || docs ? false : prev.loading,
loading: false,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we keep the oauthResponse?.error logic here? If not should we just remove the loading and depend on whether it is defined in the prev?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea in this code was to use oauthResponse?.error being defined as a way to check that the operation is complete and set the loading state to false (but create an escape hatch. for the docs since no oauthResponse is created inside the docs).

prev.loading will be true in all cases, and letting loading stay that way was done so that even if a response is received, the button would remain in a "loading" state till the OAuth redirect occurs, to visually indicate to the user that something is still "pending". This behaviour is present only in the oauth case, since none of the other auth methods involve an intermediate redirect.

On second thought, I feel it's a nice detail to let the user know that the redirect is pending, so what I feel we can do is to simply remove the additional docs check here, and change the oauth docs demos to return a mock error with "this is a fake error message", so that the button goes back into the default state.

Current After this PR
Screen.Recording.2024-12-05.at.6.37.27.PM.mov
Screen.Recording.2024-12-05.at.6.38.00.PM.mov

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that makes sense 👌

Copy link
Member

@mnajdova mnajdova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left one clarification. Also I feel we are over-engineering the singleProvider const by using memo there, but we can handle it separately :)

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged. label Dec 6, 2024
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged. label Dec 6, 2024
@bharatkashyap bharatkashyap merged commit 8dcc959 into mui:master Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

internal Behind-the-scenes enhancement. Formerly called “core”.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants