Consume File-Icons' element-icon service#870
Consume File-Icons' element-icon service#870nathansobo merged 15 commits intoatom:masterfrom Cutlery-Drawer:file-icons
Conversation
|
@50Wliu I'm keeping this package synced with upstream changes so users have a chance to test my fork using the latest version of the package. I strongly recommend squash-merging when (or if...) this gets considered. |
|
Same with this one. Would you be cool adding a basic test where we interact with the service and don't render the default icons? |
|
Oh, I've nearly finished these. :D I'm extending the current icon-related specs in |
|
@nathansobo, @50Wliu ... Could one of you please help me? I need assistance figuring out Jasmine's retarded Promise-handling because AFAIK, this shit shouldn't be happening:
I need to delay the next bunch of assertions for the |
|
I'm still trying to figure out when exactly to use this (I was completely off the mark in a previous conversation), but try calling |
|
OMFG, that explains it. What the hell, guys, that isn't cool at all. 😢 Okay, yeah, the tampering now explains every timeout-related frustration I've had with Jasmine in the past. I stuck |
|
Done. Took up most of my day. Please tell me there's nothing I missed. |
|
@Alhadis Published as 0.213.0 and upgraded in atom/atom@afc341e. I'm really sorry that our legacy spec environment is such a pain. It's a major piece of technical debt that we need to pay off on these original packages. You probably know about atom-mocha-test-runner. We just need to convert these packages. |
|
Thanks again for all these contributions. I know it was a lot of work to upstream this stuff but it's so much better than hacking the DOM. Thanks for doing the right thing! Please ping me on any followup PRs I may have missed around this stuff. |
Don't sweat it mate, I know there'd have to be a damn good reason for using legacy Jasmine in an era when Mocha and Chai exist/ :D
I'd be willing to help, as always. Would this involve me killing more CoffeeScript...? :) |
You can kill as much CoffeeScript as you'd like as far as I'm concerned. The biggest blocker there is just making sure you're not clobbering high-value PRs when you convert stuff. As for the tests, it would basically involve switching them to atom-mocha-test-runner. We prefer to use the native node Priority-wise it would be best to start with the most important packages like |
It'd be cool if Atom used my Mocha integration, haha. But I understand if you guys prefer the minimalist and traditional dot-based look. =) <img src="https://raw.githubusercontent.com/Alhadis/Atom-Mocha/master/docs/img/slide.gif" "width="900" /> |
|
@Alhadis In general, I am very concerned about following the "less is more" approach and being judicious about adding complexity and dependencies. I scoped out your runner and it looks pretty cool, though when I see lots of features I sometimes get anxious. Can you pitch us on how it's different than the runner we're using on other mocha-based packages? What problems does it solve that would warrant the overhead of switching at this point? If you weren't the author, would you still want to use it? Also, we'd prefer to prevent a profusion of different runners. We already have some packages using the other one. How hard would it be to convert them and how open are you going to be to us being fairly opinionated on how the runner for bundled packages functions. |
Don't worry, the package is in dire need of a large clean-up. Superfluous or pointless/minor features have to go. More emphasis on JS and CSS customisation is needed, rather than adding more and more options. Bear in mind this spec-runner was written during the development of
The spec-runner is built for speed and clear, direct feedback because users are expected to be irritable and sick of rerunning monolithic spec suites all the time. I was, and I wanted to use |
The package makes no assumptions about its use case. Everything that's there can be replaced if needed. The default HTML reporter is also available as an option, if somebody doesn't like the terminal look. It's extremely extensible, but my documentation of it is embarrassingly sloppy and needs improvement ... >_> |
|
Cool, well I'd be down to explore it. Getting the tests into Mocha is probably the hardest part, so worst case we could decide to go back to the simpler runner. Or maybe we'll love it. |
|
Are there that many projects afflicted from this scourge? :( Good grief, I'm now thinking about adding a migration feature. Hopefully I won't give into the temptation to write it in Perl. 😀 |
|
Which scourge? "Perl" and "temptation" don't occupy similar areas of my brain. I do like caramel apples though. |
|
Perl is my second favourite programming language, and if you thought last year's epic CSS rehaul was anything, you should see what I'm gonna do to our embarrassing Perl 5 grammar. 😂👌 Oh yeah, I write documentation in Roff instead of Markdown, because the shit actually ain't that hard. :D Once Atom has a real-time emulator to browse typeset manual pages, you'll see what I mean. 😀 And I learn some APL. I want to master it before I die. "Normality is just a cultural construct" |
|
@Alhadis Hate to do this, but I had to revert this. I think we need to spend some more time thinking through the interaction between the imperative and declarative DOM manipulation. On initial review I missed that calling |
|
By side-effect, you're talking about the That could easily be handled by the |
|
I think storing the |
|
Working on it. Would the |
I don't think so. That method is just manipulating the model state and has no access to the view. The best place to do it is in the constructor of |
The old, path-based service did, and that was why I made my changes in the |
|
If you need to call back into the service after every update, you can do it in the |
|
The services is conservative about performing DOM changes, don't worry. :) Come to think about it, there's no need for the legacy icon-service to be called multiple times, either. It isn't like a search result's path will change and warrant a different icon... I'm now using this: etch.initialize(this);
getIconServices().updateIcon(this);
}With the updateIcon (view) {
if (this.elementIcons) {
this.elementIconDisposables.add(this.elementIcons(view.refs.icon, view.filePath))
} else {
let iconClass = this.fileIcons.iconClassForPath(view.filePath, 'find-and-replace') || ''
if (Array.isArray(iconClass)) {
iconClass = iconClass.join(' ')
}
view.refs.icon.classList.add(...iconClass.trim().split(/\s+/))
}
}Weirdly, not all of the icons are visible when the search results pane is first opened:
Note the missing icon at the bottom. |
|
That is weird. This new code structure looks better to me though. Do you need to call the disposable when the view is disposed though? Meaning do you want to say something like |
|
Should this have really gone somewhere in the |
|
Ah right, I forgot about the |
|
Well, update is only called when the result view needs to re-render. The initial render is actually performed via |
|
I'm still not sure what I could be doing wrong, then. :( What do I need to call? The etch.initialize(this);
getIconServices().updateIcon(this);
this.update();
}EDIT: Okay, no, |
|
@nathansobo I have no idea what to do. :) The closest solution I can see is what I attempted doing in #971, with the |
|
@Alhadis, sorry, busy weekend. Do you have a branch I could pull down and a way to reproduce the issues you're seeing so I can help? |
|
Hey @nathansobo, I'm afraid not. Things were becoming very messy locally so I ended up deleting everything I had and working off #971 instead. See #974. |
4 participants
This PR applies to the
tabspackage what's been described inatom/tree-view#1146for thetree-viewpackage. The PR's updated wording describes this scenario best, so I'll just copy+paste:I realised too late that your icon-service fulfils a different purpose from what our package needed. We wrote our own instead, which is built on a dubious but (currently) stable foundation of monkey-patches.
Opinions differ on the subject, but mine is that monkey-patching code you didn't write is bad, and should only be used as a last resort (DOM polyfills notwithstanding). Which is precisely what I've been forced to do to get dynamic icon-assignment working.
This needs to be fixed at a formal level, because:
Patches don't persist if File-Icons is deactivated and reactivated.
I've actually chosen not to fix this, because it would step outside the expected lifecycle of the package. E.g., when a user deactivates a package, they expect it to leave no traces in the workspace. I also can't imagine this happening too often, but still...
Any innocent change to your packages could break stuff.
The obvious danger of monkey-patching what wasn't expected or supposed to be changed. We have specs to alert us of breakage, but there's no telling what would be involved in the repair. We both know this is the wrong approach.
Now, I don't know how the Atom team would feel about adding support for third-party package services. Ideally, this would be addressed on the level of Atom's core icon-API. However, the differences of our needs (as well as the specific use-case of our needs) make me hesitant to propose a change to your existing service, especially because @as-cii has stressed he prefers keeping its functionality simple for the time being. In light of that, it would be more appropriate and ergonomic to support a third-party service in the interim, should a mutually-compatible solution be realised in future.
What this service does
The
file-icons.element-iconsservice, when consumed, provides a function to add dynamic icons to DOM elements. The function is to be called by the package on any element that's supposed to represent a filesystem resource (either files, or directories):Calling the function returns a Disposable that clears the icon-node instance from memory, which should be done once the view is destroyed.
Note there's no requirement to specify whether a path is a file or directory. Our heavy-duty filesystem API takes care of the heavy lifting... I've even plans to separate it from File-Icons in the form of a standalone Node module, so other package authors can benefit from my hard work too. :)
Related pull-requests
atom/tree-view#1146atom/tabs#412atom/find-and-replace#870atom/fuzzy-finder#281atom/archive-view#47