Sessions is temporarily moving to YouTube, check out all our new videos here.

Too Many Tabs - The Ember Project File Tree

Paul Doerwald speaking at Ember London in September, 2017
14Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Love ember --pods and the new module unification structure? Annoyed by countless editor tabs labelled "component.js" and "template.hbs"? This talk will demo a new way of organizing your Ember project.


Transcript


So here I am to give a very short presentation on something that's bothered me a little bit about working in Ember JS and that is the tabs. And the reason I'm presenting this is just 'cause I want to get a sense from any of you, am I the only person that feels this or do you get frustrated by it too? Because it drives me nuts enough that I've come up with a little solution for it, which is a bit hacky, but I'm looking forward to, not my presentation but your response. And whether you love it or hate it, so. So this is basically the problem. Don't focus on the content, that's not important. But this is pretty straight forward. So you got a component. I'm using the pod structure because I happen to like pods more and it's what the file, the modular unification naming structure is going to be. But here it's straight forward. We've got a component. We've got a template open. Nothing weird about that. This is still okay. It's gotten a little bit weirder. It's got component template, component template. But I can see which one's which. So this belongs to archiver item, this belongs to log entry. I'm still understanding it. But I notice that when I'm coding, I'm moving back and forth between tabs all the time. And it gets a bit more challenging when you get to this point. And I don't know how much this is the reality for you. But I find myself, when I'm programming in Ember, to be spending most of my time - well a surprisingly large amount of time just managing tabs. Pulling something over here so I need the router over there because you need to have access to the router, but I'm working on the route. And then I probably, well I lost track of the template for the route. It's probably back here. And then these are the components that I'm working on. But typically I'm working in a whole lot of tabs all at the same time. And command zero though nine are just not enough. And command nine is really hard to reach. So that starts to get me kind of annoyed. So, and this is just crazy. I mean look at how many tabs I have open here. It's hard to find out. And if I want to find out which tab that is, I have to mouse over it and hopefully the little tool tip will appear. It doesn't always. And then sometimes I might be on a tab that's over here but I can't actually see what tab that is because the title is completely obscured and I can't tell from looking inside because there's no indication of what that component is, like whether it's the archiver component, or this is obviously a template. But it could be the archiver item component or it could be the log entry component. You can't really tell just by looking at the code. You need the information in the tab. So I've seen people come up with this kind of solution. I was recently watching a Tom Dale talk and he had multiple panes set up. So here I have my route, which I'm looking at and a couple of templates for two different routes. Although I only have one route open. Can any of you tell me which route that is? 'Cause I'm not really sure. I know that's a problem with the module layout. And then down here I have the four components open, at least most of the way. And this is in contrast to what you have in the rails world, which is where I'm coming from like Nick. Where there's an archives controller. I can see what its called. I see it there. And here are all the controller actions. And that, although with an underscore, in a weird way, it does correspond with the index action and everything just kind of fits together. And I can look and I can do work with a small number of tabs open. So I'm not constantly sliding tabs back and forth, trying to organise what's what. And I find that that sliding tabs back and forth creates a big cognitive overhead for me. So I came up with a little tool that I call ember-defenestrate. Which technically means throwing someone out of a window, rather than throwing out the window. But I'm trying to throw out the windows. And by windows I mean tabs. So this tool watches parallel source trees and it's a bit of a hack, so don't judge me on this. And I'll also confess that I wrote it in Ruby. 'Cause I'm just stronger at Ruby than in JavaScript. So it manages parallel trees and it creates these .mbr files. Get it, ember files. That are basically concatenations of all of the other files. So instead of lots of tabs, I turn it on its side and I now have one long file. It's different but I find it kind of easier to deal with. And then what it let's me do is let's me treat routes and components holistically. I find that if I'm working on a component, I'm never interested in just the JavaScript part of the component. I'm never interested in just the template part. I'm always working on these two together. Because I'll make a change in the JavaScript and it has a corresponding change in the template. And so I find it cognitively easier to move up and down in the same file rather than back and forth between tabs. Back and forth between tabs would be fine, except when you have so many tabs, it becomes problematic. So I'm gonna do a really quick demo that shows how this works. I'm just going to run that script. It's going to generate the ember-defenestrate tree. And so what it's done now, is it's created these two directories. I should have shown you before what was there or that there's nothing there. We have an app directory and inside are all the components. There's the monitor route. Here are a bunch of files. They're all called .mbr. So to make it interesting, let's go to the archiver item. This is the one that I was showing you earlier. Here is the archiver item. And here is the template. And I find it's kind of easy, a moment ago I had mouse leaf there just to be a little crazy. Oh jeez, now I have to... See this is also really hard. How do you move panes, or tabs between panes, without actually using your mouse? It's not an easy keyboard control to push them around. So let me go to layout. Single. Which one do I wanna? Okay, I'm just gonna close all of them, 'cause I do that often, I just close everything, I start again. Archiver item. Template archiver item component. Okay, here they are. Let's say. Well I'm gonna just save this. And I can see here it's now changed it to mouse leaf. So I can actually work sort of in these parallel windows. So I don't lose access to the ember file hierarchy. I just have a, what I think, is a convenient alternative to it. And if I were to, let's say, here's the better example. So let's say, okay. I'm just going to touch, no. Echo foo to style.sess. So again, future module unification structure. You can have style sheets inside the component. I save that, we go back here, and there's my style sheet. Its just kind of embedded it in there. That's kind of the idea. That's what I'm pursing, or that's what I tried. I've worked with it a little bit. I find it to be an improvement. I'm a little guarded about that. But I'm just gonna, at this point, kind of turn it over to you and ask you what you think. Love it, hate it? I want to hear. Yes, Will. View. I have not used any of them. Yeah. Okay. Okay. Okay. Yeah, the slide that I didn't prepare would have gone back to PHP. When you have the PHP and then right in line, you have some SQL. And it's brutal but it's so easy to understand. You just read down, oh yeah this is what happens here and here's the html that gets output. You don't have to jump between scripts. I'm not saying that's the right way to do it. But there is a simplicity to that, that is appealing. Any other thoughts? Yes, with the purple hair. So this structure embraces the pod structure, or the pod modular unification syntax. It does not work with the old, with the standard, the normal Ember syntax. It could be expanded, too, easily enough. I saw in Nick's example, he had a bunch of files called new js and new hbs. It's kind of the same problem, just a different flipping around of it. But yes there's no reason why this particular software wouldn't work effortlessly. - [Student] Thank you very much.