 Hi, so my name's Tom. I'm a front-end web developer at a company called With Associates. We're a digital agency based up in Hackney, and we make websites and apps and other webby stuff like that. My talk today is going to be pretty short, essentially just going to be running through my first Ember app. I'm reasonably new to Ember, I've been coming to the meet-ups for a little while. But yeah, it's my first Ember app that I've worked on from the beginning and it's gone into production. And I'm going to talk a little bit about reasons for choosing Ember, some of the design decisions behind the apps, some things I liked about Ember and that I found useful, and also some things that I found a bit tricky or that tripped me up a bit. So a quick bit of background about the project. We worked with an artist, illustrator, author called Marion Duchard. You may have seen her work around, if not check it out, it's really cool. And basically we made a promo site for her book series, which is called Let's Make Some Great Art. And these are sort of beautifully drawn, fun activity books for kids. And so along with the promo site, we made some sort of web-based drawing apps, which were essentially digital versions of the activities in the books. We made a bunch of prototypes and some were pretty silly, but we picked three and built them and they looked a little bit like this. There's no not using any framework there, it's just sort of vanilla JavaScript and a little bit of jQuery and some sort of custom scaffolding around which they're built. But they worked pretty well and people used them and they used them quite creatively to make stuff like this, which is a sort of punk rock monster with a big bogey hanging out her nose and a sort of relaxing beach scene and this kind of fashionable cowboy with a nice shirt and a turtle being sick. But so those all looked really nice, but the problem is the code looked a bit like this. You know, it's just one big long file with no comments or documentation and some sort of bizarre naming schemes and decisions in there and really I was the only person that fully understood it because I built most of it. So maintaining and iterating on it wasn't that fun. So when Marion came to us and asked if we could make some more changes so that she'd be able to use the apps in an exhibition she was having up in Scotland where the kids would sort of be drawing on iPads in the exhibition space, I was a little bit worried and I looked at this code and my face looked a bit like this. So I decided to sort of learn a bit of Ember and rebuild it in Ember rather than sort of digging through the old code and trying to bludgeon it in there. So it's not really modelling much data or anything like that so it's not exactly a prime candidate for a full on framework like Ember. But I think there's plenty to Ember that makes developing any kind of front end application really nice. So why Ember? Well I wanted a code base that was easy to maintain and iterate on unlike the previous one and that meant having some structure and conventions and I didn't want to have to plan these out myself in advance or sort of retroactively try and fit them in so Ember's good for that. I wanted to make use of the work of plenty of smart people who worked on Ember which left me to do just the fun bits like the drawing code and stuff like that. And so this is the Ember version. It looks very similar, it's got some new design elements and some different buttons and stuff like that and it didn't take too long to port across. There wasn't a huge amount of code reuse but now it's iterating on this and maintaining it's really easy. If we want to add in some new functionality like a new modal or a new button that does something else it's just a case of adding in another component. So some of the stuff that I liked about Ember components, components are really cool. Tidy units of functionality that do one thing well and they're supposed to be reusable where possible. I didn't worry too much about that because I think they're really great for just packaging up any nice tidy unit of code whether it's particularly reusable elsewhere or not. And they're really simple and obvious. It's sort of one JavaScript file and maybe a handlebars file. So it's a good way to keep the code nice and tidy. So this is just a simple component that we're using it which is just an overlay. It's got some content in between the handlebars tags that we want to show at a certain point and the isVisible flag is just its computed property on the controller to say when the overlay should show. And so in the JavaScript it just looks like this. There's another computer property there which just sets the display CSS to block or none depending on whether we want the component the overlay to show. But one thing I found a little bit difficult or a little bit confusing with components was how to get a component to do something for you on command. This is the sort of main interface for interacting from a parent view into a component and back which is just basically a bunch of sort of shared data bindings. So I think what you're supposed to do is make the data available all the time across these bindings that you want the parent view to be able to interact with. But that was a bit tricky with the canvas component because the data I wanted to send back up was a computed PNG data URL which on the iPads it took about a second to compute that and during that time the interface locked up. So I really only wanted to do that under specific scenarios when the user clicked save or something like that. I'm still not really sure the best way to do this but we opted for an in-between way which is basically this function update value gets debounced when the mouse up or the touch end happens and then if the user starts drawing again during that half-second it will just cancel updating that value. In components like views they have access to all the interaction events like touch events and this isn't really ember specific really but I thought it might be nice to just run through it quickly in case anybody's interested. So in the component you can just alias the mouse methods to the touch events but you have to do a little bit of work to get sort of compatible event data through that. So for a single touch it's quite easy because you can just do the mouse event or the touch event but for multiple touches which you wanted so that you can draw with lots of fingers it's a bit tricky because you have to keep track of the change touches through an ID like that. One other thing about components and events unlike jQuery or playing JavaScript where your event handler the context is going to be the DOM element in a component it will be the component or the view which is fine once you get used to it but it tripped me up a couple of times when I was porting code across. And then another thing services they're not really the most exciting bit of ember but I think they could be useful for all kinds of things a good use case that I came across was for doing responsive interfaces where you can obviously do a lot with just CSS but there might be times that you want your controller or some logic in a component to know what the view port is like to hide or show some specific interface or do things differently. So this is a really simple view port service that's in there which just gets the window width and height and it's got computer property whether the view port is a mobile device and then it's getting injected into the component and the controllers so that we can use it in there like this in the template where I'm only showing certain user interface elements when it's on a mobile device and also in the canvas component where I'm using some CSS properties to zoom out so it's not kind of massive on the screen so it's useful to know that in there too. The other thing that's cool ember app kit or ember CLI now when I was building this CLI wasn't quite ready so I used ember app kit which was really cool I've got lots of fun stuff in it but for me as a beginner learning ember all the stuff around the ember code like the ES6 transpiler and broccoli and bower and NPM if you're not familiar with those things at all then that can be kind of daunting just getting to the ember specific stuff and to compare with my single JavaScript file at the beginning that the app kit tree looks like this which is also pretty daunting if you're new to ember and you don't really know what's going on but I think now this is really useful for keeping code separate doing what it's supposed to be doing and yeah so my talk was supposed to be a short talk so that's pretty much where it ends but I just show you some photos of the apps in action so this is setting up the iPads this is the exhibition space and there's some in use and some of my favourite drawings that came out of the exhibition there's this cool guy in a red hat nice stick lady sort of rainbow bus which I liked Mona Lisa clan face on Teenage Mutant Ninja Turtle and yeah that's it so thanks Q. Could you talk us through the ejection stuff you did with the viewport again I found that really interesting I haven't used the ejections yet so I tried to and failed for most of the weeks so this viewport service up here it's just got a... you can put a bunch of functions on it it will essentially act like a global variable when you inject it into here so what we're doing is ingesting this viewport service into the component and then in the component you can just access it as a property on the component itself so .viewport.isMobile Q. In your naming convention you're about to last screen you're injecting so app.inject component obviously is where you're injecting it Q. Yes Q. Then viewport is the name of this so this is a bit confused about the ES6 transpiler but this gets imported as viewport and then sorry so it's viewport and then gets injected into the component with this namespace Q. So service viewport is the name in the actual container and then viewport is the name that's exposed to us Q. What that's missing is where it registers there's a line probably above the service where it registers that service as service Q. In this example that's probably not necessary right? Q. No I just picked out these lines just to show how it's used in the app I mean Q. Is it just too clarified so appkit and CLI now if you put file in app slash services slash viewport in this example it will be made available as a module with that namespace and then the resolver knows when you say service code on viewport it will go and find that module load it in create it and sub it and then inject it in all right places Q. With that with the namespace in the second Q. So that's the property name it will get on the target object Q. Any other questions? Q. But before and after Q. Yes Q. I reckon there's probably less code now there's less code now but it's just split up amongst a bunch of different files for doing stuff like you see how easy the overlay component is when I was written in jQuery there's a lot of sort of like handling interaction events and where it's on in the ember vision it's just toggling a flag and it shows or it doesn't show so I mean there's obviously more code in the ember vision but I've only written a small part of it Q. Is it available to more comments Q. Yes, yeah maybe you can correct me from wrong Jamie but if I put the name of my component after this just inject it into a specific component