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

DevTools: Show component file path #16497

Closed
Cretezy opened this issue Aug 19, 2019 · 17 comments · Fixed by #17567
Closed

DevTools: Show component file path #16497

Cretezy opened this issue Aug 19, 2019 · 17 comments · Fixed by #17567

Comments

@Cretezy
Copy link

Cretezy commented Aug 19, 2019

Do you want to request a feature or report a bug?

Feature.

What is the current behavior?

The new DevTools doesn't show the component file path as did the v3 version.

What is the expected behavior?

It would be great to show the component file path, it's a really important feature when working in a large codebase.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

React DevTools v4 is affected, v3 had it.

@gaearon
Copy link
Collaborator

gaearon commented Aug 22, 2019

@GavBaros Please be more specific in your feedback. This is not helpful.

@hugos
Copy link

hugos commented Aug 27, 2019

I agree with @GavBaros , in this new version (v4), we cannot get file locations which really slows development time, fix this asap.

@montogeek
Copy link
Contributor

montogeek commented Aug 29, 2019

You can get your component file path by clicking in the "Log this component data to the console", icon is like a bug, and then copy the path from the Console.

@bvaughn
Copy link
Contributor

bvaughn commented Aug 29, 2019

File info isn't shown in the top level UI anymore because there are a lot of important things fighting for space in that UI. You can still see it using the debug button though.

file-infoKapture 2019-08-29 at 8 38 46

Is this enough to satisfy your use case @Cretezy? Seems like it should be?

@Cretezy
Copy link
Author

Cretezy commented Aug 29, 2019

I think doing 4 clicks for something so basic is way to much. Putting it at the bottom (or top) of the info panel doesn't seem like it would block anything, since it's quite empty and would be very helpful (at least a copy path button would be small)

image

@bvaughn
Copy link
Contributor

bvaughn commented Aug 29, 2019

I think doing 4 clicks for something so basic is way to much.

To counter this, I don't think people use this info / look for this info often- so I'm not sure it needs to be available at a glance. I think putting less accessed info behind a click or two isn't so unreasonable.

I don't think 4 clicks is right. You have to click to select an element to begin with. Then it's:

  1. Click the bug
  2. Click console or type "Esc" to open the bottom console
  3. Click to expand the logged element (at which point the file info is already visible)

Putting it at the bottom (or top) of the info panel doesn't seem like it would block anything, since it's quite empty and would be very helpful (at least a copy path button would be small)

Your screenshot looks like a pretty extreme edge case. Many people run this extension docked to the bottom 1/4th or so of their browser window, where there is much less height and adding it to the bottom would require scrolling.

@Cretezy
Copy link
Author

Cretezy commented Aug 29, 2019

Even 3 clicks is a lot. I know I used it multiple times a day, so does my co-workers. Maybe adding an option to display it at the bottom would be a good compromise? Even off my default is fine, but the ones that use it would be able to turn it on.

IMO, dev tools should help developers do their jobs better/faster, and an option would fulfill that purpose without impeeding others.

@ahmedam55
Copy link

I agree with @Cretezy, the old place that this piece of information where was way more accessible and easier to reach than now.

@hdwivedi9
Copy link

Please show the component file path by scrolling. It is very important for large projects. Doing it in 3 clicks is waste of time.

@hugos
Copy link

hugos commented Sep 2, 2019

I agree with @hdwivedi9 , in large projects this is such a waste of time, just put it in the old place as it was much much better.

@bvaughn
Copy link
Contributor

bvaughn commented Sep 2, 2019

I don't think further comments just saying "please add this" add much value. Copy-pasting Dan's response from another issue as I think it also applies here:

There are many people subscribed to this repository. We don't want to spam them with the same comments every few hours. Additionally, we personally use GitHub notifications. If this thread gets bumped every day with a "+1", we'll eventually have to unsubscribe from it to reduce the noise. Which is likely the opposite of your intention.

Before commenting, please make sure that you're adding something that wasn't said before. If you see a similar comment to what you wanted to write, just add a 👍 reaction to it instead.

Thanks for understanding.
We appreciate your feedback but 👍s are enough to help prioritize tasks.

@bvaughn
Copy link
Contributor

bvaughn commented Dec 10, 2019

I had the chance to look into this a bit last night and this morning and here are my thoughts.

I don't think this was intentional, but the screenshot in the comment above is pretty misleading:
Screen Shot 2019-12-10 at 8 20 04 AM

Source paths are never this short. In practice, the string would always either need to be truncated- so it would not end up showing the file name or line number:
Screen Shot 2019-12-10 at 8 23 58 AM

Or it would need to be the file name only, without the path:
Screen Shot 2019-12-10 at 8 22 19 AM

Neither of which is actually that helpful if your goal is to copy a file path so that you can open it in an external editing tool. If we were to display the full string, and allow it to wrap, it would take up even more space.
Screen Shot 2019-12-10 at 8 27 43 AM

The only place I feel somewhat okay about putting the info is at the bottom, but I think this will often mean that in practice, it's not visible without scrolling (since most components have several props/state that would push it down):
Screen Shot 2019-12-10 at 8 33 32 AM

I guess I could always make it a configurable option- but more options means more maintenance burden and I don't think this clears the bar for one.

Maybe the best compromise would be to show the name only, at the bottom, and have a copy button for the full path with line number:
Screen Shot 2019-12-10 at 8 44 27 AM

This would still require a bit of scrolling but... I don't think there's any way around that without harming the common case UX.

@montogeek
Copy link
Contributor

Thanks @bvaughn

@Cretezy
Copy link
Author

Cretezy commented Dec 10, 2019

@bvaughn This is already much better. Having a single option to make it copy the full path would be the best way though, since it's simple and all editors support opening by full path.

@bvaughn
Copy link
Contributor

bvaughn commented Dec 10, 2019

@bvaughn This is already much better. Having a single option to make it copy the full path would be the best way though, since it's simple and all editors support opening by full path.

This is literally that. The partial path is shown but the copy button copies the full path. That's what I was trying to say with this:

Maybe the best compromise would be to show the name only, at the bottom, and have a copy button for the full path with line number

@Cretezy
Copy link
Author

Cretezy commented Dec 10, 2019

@bvaughn Ah sorry I misunderstood! Thank you very much!

@sagar-gavhane
Copy link

Still, we can get a file source by clicking the right-side source icon.

Screenshot 2019-12-11 at 11 52 02 AM

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

Successfully merging a pull request may close this issue.

8 participants