-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
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
[Button] Change LoadingButton prop pending to loading #21593
Comments
Thanks for raising this API inconsistency, much appreciated. I believe the closest prior discussion we have is in #21389 (comment) with @mnajdova and @eps1lon. |
Looking at the semantic, we have:
The use of pending echos back to https://reactjs.org/docs/concurrent-mode-patterns.html#the-three-steps. I don't have any strong preference, I think that we can settle this with a vote, the end goal is to make it intuitive to developers.
|
@oliviertassinari Good idea, I still think that the word loading is much more used and specially in React components. UI framework examples: React Bootstrap, React spinners, React Semantic-UI, Ant |
It seems that we can go into the direction proposed by @adamsr123 |
If you look at the component you'll see that these props are in fact describing different UI patterns. Naming them differently is very much intended. Before reading the concurrent mode docs I would've probably agreed. But it's now apparent to me that we should distinguish these patterns in naming so that they aren't misused. |
@eps1lon It isn't clear to me that "pending" is any more accurate than "loading" in this case. Neither prop name is ideal for this case. Unlike Autocomplete, which can itself be in a "loading" state, this button is indicating the state of something else -- the button itself isn't "pending" or "loading", rather it might indicate a pending transition or that something else is loading. As far as the concurrent mode docs you referenced, though the distinction between "pending" and "loading" is useful in discussing the details of how to leverage When the button is triggering changes in another part of the screen, that portion of the screen being updated could be in either the "pending" state (i.e. still showing the previous contents) or "loading" state (e.g. showing a skeleton representation of what is coming) with regard to the concurrent mode terminology. For the display of the button, we don't care about that granularity -- the button doesn't have three states ("pending", "loading", "normal"), just two. In either of the pending and loading states, it is still the case that something is loading, it is just a difference in what is being shown in the area that will be updated when the loading completes. The most accurate name would be a |
I would have to agree eith @eps1lon on this one, we should follow react’s terms for describing the patterns which are already defined in their implementation. The button itself is not in loading state, bit it can show a pending state. The name of the component is suggesting that it can be used in use cases when something will be loading on the page, but the state it has is |
While naming is a hard problem, let's take a step back and answer this question: What does a great name accomplish? I think that the priorities and important points are:
I think that we should go with "loading":
https://reactjs.org/docs/concurrent-mode-patterns.html#preferred-pending-skeleton-complete I agree with the point of @ryancogswell in #21593 (comment), It feels that "loading" includes the meaning of "pending" with a broader one. I think that the objective of the prop should be to signal to the users that the UI isn't idle, something is going on behind the scene. "busy" could almost be a better name if taking the 3. Communicate intent track alone. |
Exactly. It will always tell if something else is pending. Sometimes this will indicate loading. This makes pending the better name.
It is a special case of a pending transition. It is not a more general case. This is not an argument for loading.
Again, this is a fallacy. Just because we used to do something does not mean it is the right thing to do. Concurrent patterns are new and it is just wrong to compare these to past terminology that have no explainer. We just used loading if we load data. Reusing this terminology for transitions sets the UI up for failure.
Could you engage with my argument instead of repeating the ones I already refuted?
You agree with my point. In a React ecosystem with concurrent mode "pending" is the better name because of consistency.
You're repeating consistency arguments.
Also supporting my argument. The intent is to trigger a transition. It might load data or trigger a suspense boundary in the broadest sense. |
@eps1lon Are you arguing for
In what case is a transition pending when it isn't because something (code or data) is loading?
I disagree. I don't feel like either is broader. "pending" focuses on the state of transition, "loading" refers to why the transition is pending. Why haven't we transitioned yet? Because we're still loading something. So the question becomes, is it more intuitive to refer to the transition state or is it more intuitive to refer to the activity that is the cause of the transition state. I would argue that developers will ask, "what is the property I need to set to show that something is still loading?" more readily than asking "what is the property I need to set to indicate that my transition is in a pending state?"
In what way does using the term "loading" set the UI up for failure? If someone isn't aware of the new capabilities provided by concurrent mode in React and how to use them, Material-UI using "pending" for this prop name isn't going to make them more aware. And if a developer does understand the nuances of concurrent mode, Material-UI using "loading" for this prop name is not going to lead them astray. |
@eps1lon Agree, the argument is only that changing people's habits is hard, leveraging what they already know is less effort (which is a valuable property). It doesn't have an implication of being right. The majority can be wrong.
The two are close but different. consistency !== intuitiveness. A counterexample: we could be using "foo" for the prop on the whole codebase making it consistent, and yet, it won't make it intuitive. I think that consistency is necessary for making an API intuitive but isn't sufficient.
My assumption was different, I believe the transition state is second-order, it's a concern that leaks outside of the responsibility of the button, it's the application (or the suspense component parent of the button) that is in a pending state, not the button. What's displayed in the button when the prop is true? A loader, tree dots, a circular progress. |
I vote for |
You understand that you're saying that an inconsistent API can never be intuitive? We would need to name every prop the same even if they do different things. That's definitely wrong. Consistency might be a characteristic of an intuitive API but consistency is never a goal in and of itself.
So we name it
The API of concurrent mode doesn't matter. The mental model does. |
@eps1lon To me, the most compelling consistency argument is regarding being consistent with itself (which is why I asked before whether you also wanted to change the name of the component). For the moment, we have decided to call this I actually like "pending indicator" as a generic term for the loader/spinner, but for reasons I can't fully explain, I think |
@ryancogswell I have a separate discussion & demo for renaming the JSX tag here. Yes, 'pending' captures a wider use-case. BTW @oliviertassinari Thank you for being open to discussion. "Naming things is hard." |
#21903 is a good example why "consistency" is not an argument for names. We use different words in language to describe different concepts. And |
What about: we try It seems to come down to:
Arguably we could also rename |
Sound fair to me, thanks for the consideration. |
Does this proposal include renaming the props |
@landon912 Intuitively, I would propose that both |
Hi Devs, |
@Divyansh-sysadmin-creative please open an issue with a reproduction. |
I'm very happy to see the new pre-release v5.0.0-alpha.1. I noticed something:
Autocomplete
component has a prop calledloading
.LoadingButton
component has a prop calledpending
.For convention, I think all components should use the word
loading
. Also it feels it makes sense after the component nameThe text was updated successfully, but these errors were encountered: