Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loader states #27

Closed
TheGooner93 opened this issue Feb 23, 2022 · 6 comments
Closed

Loader states #27

TheGooner93 opened this issue Feb 23, 2022 · 6 comments

Comments

@TheGooner93
Copy link

Hi, this is great work.
I think it would be a great idea to also incorporate a isLoading prop to control any loading states? Wdyt @anatoliygatt ?

@anatoliygatt
Copy link
Owner

Hi @TheGooner93. Thank you, glad you liked it!

I'm not sure what it's actually for, nor have I ever seen this pattern being used in any of the libraries that are implementing form inputs (including toggle switch).

I can see two possible use cases where isLoading might be useful, but we can easily overcome it with the already existing attributes and best practices:

  1. If you want to make a toggle switch's state immutable while submitting a form, you can use a disabled or an aria-disabled attribute for this very purpose.
  2. If you want to load a form's state from an API, you shouldn't display a form in an unknown state in the first place. Use some sort of a loading spinner and then render the whole form whenever its state will become available.

Let me know what you think!

@TheGooner93
Copy link
Author

Yeah what I'm thinking of is your point regarding integration with an API. Suppose toggling this switch is not being used as part of a form, but as a standalone input to perform an action ( for eg. adding a product to a wishlist in an ecommerce website) then a loading state would be sensible.

The loading state within the input(as opposed to an entire page loading) would be definitely optional and nice to have. Feels like better UX too imo

@anatoliygatt
Copy link
Owner

I see. In this case, I would use another best practice, optimistic UI. Think of a "Like" button on Twitter, when you click on it, it will animate immediately and then if something goes wrong, it will just restore itself to the original state and show some sort of toast with an error message.

@TheGooner93
Copy link
Author

Yes exactly. I do have a PR ready for this. I will update once I fix the snapshot tests.

@anatoliygatt
Copy link
Owner

anatoliygatt commented Feb 23, 2022

Well, PR is unnecessary here. When implementing optimistic UI you can, for example, set checked to true immediately and then set it back to false if an error is returned from an API.

@TheGooner93
Copy link
Author

Ah I see what you mean. Lets close this issue then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants