Repository navigation
Improve UX of finding full key value #18702
Description
The current behavior
The full value of the key is very difficult / impossible to find and use in the interface of the React Devtools.
Only managed to find it by accident :(
The expected behavior
The key is visible in the props list to the right.
Detailed Proposal
As mentioned below in #18702 (comment)
Add a light divider and new section in the props panel to the right.
Potentially also add a question mark that shows an explanation about the fact that things in this section are not really props.
Ref (Original implementation): meta/react-devtools#328
Activity
bvaughn commentedon Apr 22, 2020
This isn't a bug 😄 It's the intentional design.
The key is visible right in the Components tree. 😄 You're hovering over it a lot in the attached video.
The key isn't listed as a "prop" on the right because- at least for the moment,
keyisn't a prop. It won't be passed through to a component as part of thepropsobject parameter.And it's often useful to show inline because it's the only way to uniquely identify components in a list (like your
DeleteLi) which would otherwise look identical and require you to select each one.Sorry this caused confusion! If you have concrete suggestions for ways to improve the design, we're always happy to hear feeedback! Adding it to the Props panel would cause more confusion than it would help though, I think, since it's not a regular "prop".
bvaughn commentedon Apr 22, 2020
PS If you want to know the full value of a truncated attribute, you can double click to select it and then ctrl/cmd + C
karlhorky commentedon Apr 22, 2020
This issue is about the full value, which is super hidden (either by hovering for a long time or copying).
Would it be possible to get a second opinion on this questionable design decision?
karlhorky commentedon Apr 22, 2020
Having an inline button that appears on hover to show the full value would also be acceptable, in case it's not possible to put it somewhere in the right pane.
bvaughn commentedon Apr 22, 2020
Hovering for "a long time" means just hovering for the same amount of time the OS+browser takes to show tooltips, right? (DevTools doesn't make that time any longer.) 😄
karlhorky commentedon Apr 22, 2020
Yep, I don't mean to say it does take longer. The UX of standard OS browser tooltips is also not good.
My point is that there is low discoverability here, because so many other things are well designed in the Devtools. This is hostile not only to experienced developers, but moreso to those who need it more, beginners.
karlhorky commentedon Apr 22, 2020
I guess the best would be to just not truncate the value, if you're not going to visibly surface it elsewhere. But I guess you have a reason for not doing that.
bvaughn commentedon Apr 22, 2020
Yes, although it's a bit involved.
The reason we truncate values is because of auto indentation which offers a pretty large UX bump for developers working on large apps (like in Facebook).
Auto indentation works better (or rather, avoids the undesirable behavior of shrinking the indentation size to 0) when the width of components is less. Width is determined by: length of component name, number of badges, and size of key.
I chose to favor indentation behavior, even at the cost of truncating large keys, because I think it's the more important UX. Also because I think large keys aren't very common, and/or that keyed components can often be identified in other ways (like using the element picker or the hover-on-highlight UX feature).
So given this decision, the question is: how best to truncate? I could write a JavaScript solution that avoids truncated unless necessary, but this can get a bit complicated given the way our auto indentation calculation works- and adds overhead to the very performance-sensitive phase of scrolling. So I made the decision to go with a CSS based
max-width.It's not ideal in all cases. Certainly not in the small one your example app shows. But I think it's the right trade off for the most common cases, given the above considerations. 😄
karlhorky commentedon Apr 22, 2020
Yeah, that doesn't sound great either. Complex and potentially a maintenance burden.
Hmm... what I'm suggesting is that this can be improved without needing to affect the solutions for other constraints though. In other words, why can't we have both good indentation and good UX for showing
keys?Here are a couple of options:
Other, less desirable options:
These are just off the top of my head. With more brainstorming, even more design options with good UX can be found.
bvaughn commentedon Apr 22, 2020
I'm not a fan of an inline clickable icon.
I feel less strongly about the other two proposals, although I also think this is fine as is to be honest 😄 I haven't heard any other complaints about the feature, so it isn't super high priority from my POV (when compared to many other more pressing issues or bugs).
You're welcome to submit a PR with a proposal if you would like though?
karlhorky commentedon Apr 22, 2020
Ok, I would consider doing a PR for these (probably on the weekend).
If I move proposal 1 to the description of this issue, can we re-open it? Just in case anyone else gets around to it before I do?
bvaughn commentedon Apr 22, 2020
To be clear, I'm not committing to merge this. I am happy to review and consider it though.
I'm not going to re-open the issue as it currently stands because I disagree with the description and summary of this as a bug. It's a carefully considered design decision 😄 If you want to reword it to be more about investigating an alternate UX like you've proposed, then I'm willing to re-open it.
3 remaining items
bvaughn commentedon Apr 22, 2020
No worries. 😄
Sure, I'll reopen it now.
FWIW, I think showing the key above Props, in a separate panel, would probably be less confusing than showing it in the props (since it's not on the
propsobject and editing it wouldn't have any impact).karlhorky commentedon Apr 24, 2020
@bvaughn ok, I may have some time on the weekend to work on this.
Something similar to the image below (from meta/react-devtools#328) be ok for you?
gaearon commentedon Apr 24, 2020
Looks good
bvaughn commentedon Apr 24, 2020
Sure, something like that 😄
bvaughn commentedon Apr 28, 2020
Sebastian shared an interesting insight about this:
The change being proposed here could reinforce this, since the workflow is to first select a component and then look at its key (rather than the other way around- looking at a key to see which Component is in its slot).
Seems like the design of this, if we do choose to add "key" to the right panel somewhere, should reinforce the right mental model. (The key needs to look like it owns the component, rather than the other way around. It should not look like just another prop.)
karlhorky commentedon Apr 29, 2020
Hm, interesting idea... teaching this mental model via the design may not be practical from a design or user expectations perspective though. Making the interface more confusing will not teach people anything, it will just make Devtools harder to use.
Putting the
keyvisually "above" the component somehow would be pretty confusing, if a user clicked on the component. The user would expect to see the component itself, not thekeyfirst.Other approaches that don't have
keyhigher in the visual hierarchy may... work? Maybe going back closer to the original design by makingkeylook less like an object key and live on the same level asprops(remove the colon, bold the text). Not super enthusiastic about it, but maybe it would at least achieve the further distancing from Props that you're looking for?karlhorky commentedon May 9, 2020
@bvaughn any news? Maybe we can merge as it is and re-think async afterwards?
bvaughn commentedon May 11, 2020
Sorry for the delay. If there were updates, they would be on the issue or PR 🙂
I haven't thought of a UI treatment for this that I'm happy with yet (although admittedly it also hasn't been my top priority the past few days).
I don't think this is a critical bug fix that we need to land now and find a better solution later. It's a UI tweak, so we can take our time to get it right. I'll try to look at it some more this week.
karlhorky commentedon May 11, 2020
Ok, thanks for the update.
karlhorky commentedon May 12, 2020
Nice, cool solution for all of the constraints in #18737 (comment).
Thanks for your effort and attention seeing this through! 💯🚀