Open thgaskell opened 9 years ago
Wow, thank you very much for this advance!
Seems that the atom-typescript team is just waiting for native support on these classes to implement this kind of stuff. See TypeStrong/atom-typescript#253 :D
I think this would be a cool feature, but I'm honestly not sure that it belongs in tree-view. In order to implement this, we'd need some way to determine what is a source file and what is a file compiled from that source, and that would necessarily be language- / environment-specific, and we should avoid putting language-specific features in this package. In this specific instance, even though source maps are used across multiple languages (really languages of the Web platform and compile-to-JS languages), I don't think that's necessarily abstract enough to work for any language, which it would need to be to get added directly to tree-view.
Instead I think it would be better to expose a tree-view service, so packages can more easily customize behavior like this.
Thanks @mnquintana. I wasn't aware of services, but that sounds much better :smile:
A simple service might allow tree-view to provide the HTML markup of the tree, and other packages could modify it before it gets attached to the view?
A service sounds cool if it let packages to implement this kind of feature right @basarat?
@matheo thanks for tagging me in :rose:
Would definitely like a service. Also if anyone is working on it can we get some notifications for file renaming ? https://github.com/atom/tree-view/issues/433
@thgaskell this feature is greatly needed.
Any updates on this one ? Once we are starting to work with lots of files . This would be a great feature . specially with angular2/typescipe combination the file system quickly gets messy.
Hi all i am also hacking a solution to this!
It is still under development!
Current progress looks like this.
You can even start using it now at https://github.com/jaspersorrio/tree-view.
Perhaps using a plus/minus icon instead of an arrow which is used for folder-file relations could distinguish the difference?
Webstorm uses no icon at all as shown: Image from: http://twofuckingdevelopers.com/2013/06/setting-up-webstorm-typescript-on-mac/
Surprised there isn't more action in here, this would make TypeScript and Angular2 much better experience in Atom.
+1 This feature is needed.
Please.. we need this feature!
Actually there is a really easy solution which is already implemented in a tree view natively; it works under some conditions, but I believe it is useful for 90% of projects.
Most of the time .js and .js.map (and anything else that is generated like the output of .sass, .less, etc.) is added to the .gitignore
file, e.g. for angular app it would look like
node_modules/
app/**/*.js
app/**/*.js.map
So, by just using Hide VCS Ignored Files option the files are automatically hidden.
Then focus the tree view and press the hotkey 'i' to hide / show the generated files when you need to check them.
This solution is very much native and already integrated in your system, just use it.
The problem with that solution, is when you don't want to ignore those files from the repository.
+1 for this feature,
I was looking around to find a way to collapse or say "Fold" the file to a single point on the tree view.
My expectation is coming from visual studio 2015 as in visual studio any file with the same name before the .
will fold into a single node on the tree.
As the webpack suggests my project should be more modularized, I adapt the css module and write the test in the same place. If I ever need to move a component, I don't need to go to test folder or css folder to change the relative path. I think this is a decoupling on the file system level.
Allowing to fold the file with the same name is essential:
this allow to group up the files that complete a component
.js / .jsx
is the javascript of the component,
.css / .scss
is the local scoped style of the component,
.test.js / .spec.js
is the TDD part of the component.
The Idea is to group the map files or nest files which are related together . It may be through map files or it may be through a common name convention as @SenLi325 mentioned .
For example we can group all files below under single js file as a component part itself .
sidebar.controller.js sidebar.template.html sidebar.directive.js sidebar.component.js sidebar.constant.js ....and so on
So that makes our segregation easier component wise . But baby steps at least should be through map files at least . That way we can take this a one more step further as the scenario I mentioned above .
Perhaps the relations between nodes and children should be configurable With some defaults Something like
And then match by file name
I am sure many people are already aware of it, but the VS File Nesting Extension by @madskristensen might be a good place to look for inspiration on how to handle user-configurability based on naming conventions.
I see it's been a year since this was opened.
What is the current progress?
+1
+1
I'm subscribed to this thread to be notified on news. Not to read +1's. Please.
Specially when you can do the +1 to the first post of the issue.
@mnquintana are there any news on the service? Since in your opinion the tree view should be language agnostic.
Anyone knows what's going on with this? have u guys found some magic solves it ? 🍭
here, new atom user that is looking for a solution that fixes that "bug"
+1
+1
+1
Could you guys please stop spamming +1? I'm subscribed to this issue to get important notifications, not +1, please use the reactions.
Never had this issue with Angular(2)-Meteor but for a new job I have to use nG2 with Sails, so until a more elegant solution I use a simple trick explained here
Is there any other solution to this issue? Wondering why this just died rather than ever getting any traction in over a year. I really want to switch to Atom but this makes it very cumbersome.
+1
If someone is still looking for the solution:
File->Settings->CoreSettings - list the patterns to ignore the files.
File->Settings->Packages->tree-view(search for tree-view)->Settings - check 'Hide Ignore File Names' checkbox
Now the js.map and .js files are hidden.
The above is not a viable solution to this issue, it simply hides all .js files.
VSCode supports the following "**/*.js": {"when": "$(basename).ts"}
to hide generated js files when a base typescript file is present.
What we need however is a fold solution similar to ide's like visual studio and jetbrains. That way we can see the output as well as avoid clutter.
If anyone is still following i learned that Atom's tree view package supports this. If you go to your settings and click the box that says Hide VCS ignored files and add .js and .js.map to your gitignore it will hide all the generated files
@milesaylward - I gave you a thumbs up for the info, but I can't seem to get this configured to work even after adding ".js" and ".js.map" to my .gitignore
EDIT - I had to relaunch Atom (I thought I already had once) for the changes to take effect.
Much appreciated! This really cleans up Atom tree for Angular apps.
Ciao!
Hiding is not a solution. It is a cool workaround, but this issue relates to a valuable feature
, which other IDE / editors already have... I keep fighting the temptation to jump to VS Code...
I just started hacking on this issue, but I wanted to see if there's any feedback on the problem. #431 and #571 are both lacking and focus on specific filetypes. Currently, I'm determining whether a file should be collapsed into the source file if it is either the source map or the output file. The path is read in from the source map file and then ignored inside of
Directory.isPathIgnored
).Progress so far – just ignoring the files.
End goal
I feel that ignoring the files is a hack, and I'd rather fix how the views render these collapsible files. I made the end goal gif by adding markup and classes with the developer tools. It seemed to work well. The source file still opens up, and you can navigate it as if it were a directory.
Is it too disruptive to introduce a new constructor that leverages both the
File
andDirectory
classes?References #431 and #571.