Ionic, ngrx and Angular: building web and mobile apps with one code base

0 0

so hi everyone welcome to today on Iona Kendricks and angular and and building mobile and web applications with one code base and my name is Duncan I'm a software developer from Australia and I've been really lucky to work for a consulting company for the last few years or let me pretty much just too angular and so I spent about half my time writing angular applications I usually work on some crazy amount of different teams probably 12 to 15 different projects all you know usually make it to production over the year I do a lot of kickoffs or code reviews or serial committed to projects but then the other half of my time I get to do a lot of training and traveling around running workshops like here at MDC or doing Pluralsight and other things but it's really nice just doing one thing all the time so I do a lot of angular I get to talk to a lot of people I get to see a lot of mistakes make a lot of them myself but also see what other people are doing in the industry and talk with people making angular or or doing you know projects or libraries for angular so hopefully I can share some of those conversations with you today and if you're interested in this topic I think you'll find it really really close to home so who has been in this position hands up nice and high you've just written a web application with a bunch of custom logic and now you need to put it on a mobile phone and have it in the app store who's been in this position who who would like to take their web app and put it in the App Store yeah most of us can kind of relate to this situation and this is a situation I've been in for a lot of last year it's kind of the story of what I had last year and specifically kind of talking about having an angular application as your web application and an ionic application for your mobile application and I had University in Melbourne at Deakin University they you know contracted me through my company I worked for to help with exactly this story and then I also then had a school chain in Brisbane who had the exact same story and then I had an investment company in Melbourne so all of these companies what we did is we made these NPM packages for them and then now I've left where I used to work to write my own software or rewrite some software I have called food zone so it's something I've had a bunch of runs out and today I'm going to share with you what I was doing with NPM packages and more about what I am doing currently versus that so we did a lot of this with em care packages we would have this separate web application or multiple web applications and a separate mobile applications and then we were putting things the shared code the shared angular code into NPM packages so these NPM packages were great they're very robust it's not that I'm saying you shouldn't do it it's one of the the options but there's another option which I'll talk about so I started to hear about people talk about mono repos in the angular community so this is Alex Eagle from the core team at Google on angular and he's like oh you'll love mono repos too and then I see the these popular podcasts in the angular community like angular air and adventures in angular and then I hear that Google and Facebook also use this mono repo approach which is kind of crazy if you don't know that Google have just a single repository and as a developer if you commit code to master then it's just going to get consumed by everybody who's using that instantly so it's kind of a scary thought that it can be done and all these people are talking about it in the angular community because they're all mostly Google people so that kind of sparked me going well is there another way to do this and then recently an X came out which is the Narwhal extensions for the angular CLI that allows you to make a mono repo so I'm hearing all this stuff around it and learning about it and thinking well maybe I can use that for sharing code across mobile and web which is what I've been doing more recently and one of the two options I'll share with you so today we're going to be talking about you know what is the new angular and ionic but we won't spend too much time on that we'll talk about some of the options you have for code reuse we'll talk about how ng rx which is the way of doing Redux with angular can help pull code out of your components to make them more reusable and then we'll talk about your two different options so you've got an option for using NPM packages and you've got an option for using these NX workspaces so we'll be talking about these two different things so angular angularjs the first version we're not allowed to say angular one anymore or angular two were meant to forget about all this version stuff but angularjs was the first version and it kind of it's been around for seven years it was one of the first kind of big frameworks out there but it had problems it was kind of slow it wasn't so great when you scaled it it wasn't the best option but the new version of angular is much faster and having lofty goal and that is to be one framework mobile desktop and that's quite ambitious for a front-end framework but this is their goal and they're doing much better at it they're much faster it's a much better framework for putting on a mobile device and you get lots of things for it I'm not going to hack on too much about angular today I'm sure a lot of you have already know a fair bit about angular it's been the second versions been out for a while now we're at version 5 there's lots of amazing things you get the angular CLI which is a build tool for being able to start a new project but also bundle it to send to production you get awesome Doc's now you had a big framework so you get the router you get animations you get unit testing all of it in one spot one box you don't have to go looking around for all these different libraries you get a big community you get Universal for server-side rendering you get patterns like ng rx it's much more stable now and it's much faster which is great for mobile so all of these reasons are kind of one of the reasons why it's still such a popular framework for the enterprise because it's kind of one one-stop and 2016 talking about mobile is an interesting time it was kind of the first year we saw like the internet cross and more of the internet being consumed on a mobile device versus web application or a desktop so we're starting to see definitely in the company that I worked at as a consultant much more demand for our web developers or our teams to be able to also deliver just as effectively mobile applications and this is where ionic can really help who has used ionic before okay a couple of people who's heard of ionic mostly everybody here so onek basically is a way of taking Cordova which HTML CSS and JavaScript for building web mobile apps to put on the App Store but you do it with your angular skills so it's fascinating watching someone who knows angular Bo would have pretty much commit like within their first couple of days of a project on ionic even if they don't know it because it's mostly angular based similar syntax similar ways of doing things and it's very fast to learn but ionic 1 was pretty slow it had millions of installs it was super popular but it just like the first version it was kind of slow and people kind of dragged on it a bit for that but the third version is much faster and the fourth versions around the corner we'll be faster again so some of the things I really like about using it as an angular developer is it's easy to get started like a normal regular developer you can just go ionic start there's a command-line tool just like there is for angular and you go ionic start you project and choose the type you sell what tabs CD into your project and you just go ionic serve and you have it so there's a lot of benefits to using ionic for an angular shop it's kind of we've found that we've been able to be quite effective at taking full stack web developers and doing ionic with angular versus say xamarin where we were successful but the xamarin guys really needed to be good xamarin guys we couldn't just take a web developer who was okay at c-sharp and stick them on their xamarin team and be you know effective really quickly so also you get this great ability just go I own it called over run Android - - release or something like that and then boom you have your IP k or your apk ready to go to the store you know you've got to do more work from there but it really is kind of along those lines simple so it's been great for getting angular developers to do mobile but when you want to share code then you've got to think about this you get these awesome components like this so you get these ionic components that are like sliders dropdowns calendars because those sorts of things and they're really great when you use ionic it's one of the fun things about using ionic as you go oh wow these are so robust I wish I had like components from the web world that were so easy to use you can even get them for Windows and last time I gave this talk I said I but I've never met anyone who has an ionic Windows app and someone showed me so I've met one so there is some Windows app still out there so but this makes it hard to share the code across both because the widgets are so awesome they're so good for touch that you don't want to not use them when you're making an ionic app but they're no good to take over the fence and put them in your web app because they're not designed to be in the browser they're designed to be on a mobile device and they're not as performant this is changing but that's kind of the current state of affairs so it's really hard to share those across but now the ionic team are betting everything on web components and they have this library called stencil for making web components I'm going to say web components I mean like polymer style web components like browser standard web components so you're gonna be able to take what you would run in your mobile device and also run it in your web app so hopefully we can start sharing those but that's kind of just happening but not here yet so this is angular and ionic and we want to share code between the two what are our code reuse options well we've got these different things we've got components routing services and state and we have pretty much the same thing in our NIC applications and which things can we share across the two so we can really share the angular services easily and if you're using in jaracz which I'll talk about you can also share your state logic across these apps really easy and it's great for that but it's very hard to share these components because you end up using some library like angular material on the web and then ionic components or widgets on the mobile and it's very hard to cross them back and forth so it's very tricky to do the component bit but if you have your own custom components you make your own custom CSS styling and HTML then totally easy to share across the to copy and paste sucks we know that it's not going to work very well as soon as you have it in one application he pastes it into your other application and then someone updates one of the applications or one of the four applications like a main menu and then now you have to keep it up-to-date everywhere so copy and paste doesn't really work very well putting it in a folder is equally as difficult if you have like a git sub module you have a mobile app and a web app or even just two angular apps and you share that with a folder that you copy and paste between the two it doesn't quite work so well because want not necessarily versioned not necessarily easy to get it into the ecosystem because it's outside of like the angular project and so just putting it in a folder doesn't work very well either there's some things you can do besides copy and paste and sticking it in a folder and copying it into another project is using n swag for sharing code so and who's who uses swagger on their API okay who's used n swag okay interesting so n swag I thought would be a terrible idea but my friends who love to auto generate code commits me we should but five projects we've used it on it's worked every time it's been quite magical even though as a hater so basically you pointed at your swagger documentation and it will auto-generate all of your angular services all of your DT OS your view models from the server will get turns into angular interfaces on the front end you update your back-end DTO or view model and you just go in run-ins wagon and auto generates all your interfaces and services again so this is good you can probably Auto generate like 20% of your angular publication and take it mobile and web so it's pretty cool but it doesn't do a lot of it I want to get better I want to get like 50 70 % code sharing across these two because often we're making not crazy complex mobile apps it's often just line of business apps and they share a lot of features between mobile and web so this is we're making NPM packages has been quite effective for us especially if they need to be versioned between teams one team needs to be on one version of the shared code and another on a different version because they can't update just yet but it's not as simple as as you think to do this you need to follow the angular package format which is actually a real thing comes out from the angular team and they say if you want to build angular projects for NPM you need to follow these things you want to have a metadata JSON file so you can do ahead of time compilation which in the angular world means that you compile all your HTML templates offline and node before you go to the browser to save doing that in the browser means much smaller difference between megabytes and kilobytes for your build size you also need to have type definitions for your shared library that you're making in angular and you need to have DDS files you also want to make them a fez 'm or a flat ACMA script module i'm not making up that name it is called a pheasant and basically it means having all your modules brought into just one module so it loads faster and it you might want to UMD file to run it in something like a plonker or something like that and you might want to consider having closure compiler annotations for the future when maybe we use closure to crush our angular app smaller I don't want to do any of this yeah I just want to write angular code so you're gonna end up using a library to do this you're not going to write it yourself so it's even we you know putting things in empty in packages it is not as simple as you think you're going to need to use someone else's tool to do it but before we talk about that tool and the first option which is using NPM packages which is still really good and I've done a lot I want to talk a bit about energy rx and how ng ox is great for you know sucking logic out of the components who's used NGO X here okay a couple of who's used redux okay same people kind of okay so NGO X is basically the Redux pattern for angular that's what it is it's the tool to choose an angular developer when you want to do Redux and not redux library but the pattern it's a little different in angular because we use our exchange ins for JavaScript but that really helps you know in terms of using all the power of rxjs like you would as an angular developer across your state management as well so basically the reason it's really good not just for making good enterprise applications because state management is probably the hardest part of making good angular apps at scale but in particular in terms of sharing code it just sucks all the logic out of your components and you can put it in your state management and your components get much simpler and I'll show you why so if you're doing best practice state management at the moment in angular before you use ng rx you're probably going to be following a pattern where you have container components and presentation or components or smart and dumb and the container components they're jobs really just to inject things like services or dependencies and be able to connect and get users or delete entities and things like that they're the ones that have the smarts but they don't really render anything that's the job of the presentational components which receive everything through an input or an output bunch of you have probably seen these it's kind of a cool thing to do but when you do this pattern then you get a lot of abilities to tell angular not to check these presentational components and change section performance improvements other things but in state management it gets trickier when you get them nested like this and you get three levels deep and then all of a sudden you have another container component that needs the information down in this nested presentational component here and you were to go out and out and out and then most people go off I'll just make this one a container component and share state through a service best practice works great make it an observable any of any component that injects service and subscribes to this observable can then be updated great way of sharing state before you get to end your ex but the problem is as your app starts to grow out you get more services and things and then this service you know points to here and here and here and here you still end up in a mess you still as your application grows and grows States still difficult so tricky to manage and you end up with race conditions and other problems because anywhere can update anything all the time both ways and it becomes a bit of a bowl of mutable soup so this is where having a single store can clean everything up and make things easier so do a quick quick talk about what it is I might bore some of the people who have used it but basically a store is just a JavaScript object and these words are all the kind of redux II words but it's the same in njx so the store is just a JavaScript object here I've got a couple of slices of state i've got companies and contacts and it literally is a JavaScript object I can select information from the store into my component see here I could select companies but if I wanted to delete a company I don't delete it in the component what I would normally do if I wasn't using indirect Saad inject a service call the angular service it would talk to my back-end delete the company come back tell me the idea of the company that was deleted and then I would mutate my array of companies in the component and just update it right there but that's not what you're doing in Gerak's you pull that logic out of the component the component now knows nothing it just knows how to dispatch an action to ask someone to delete that company so dispatch in action with a type and a payload there the two properties that are often on it or you always have a type on an action and a payload here of an ID and the people listening for that are two different places you've got reducers and effects so in this case if it's a pure synchronous function it will just go straight to the reducer but HTTP request does not appear function pure function being an a function that takes given the same arguments will always return the same thing but a HTTP request not a pure function you might get a 400 you might get a 500 you don't know what you'll get back so in this case you listen for it in the effect and the effect talks with this angular service it calls the back end comes back if it's successful the effect will then dispatch a success action like this saying delete company success if it's an error or delete it'll say you know delete company error and you'll handle it differently but if it's successful then you listen for this in the reducer the reducer takes the previous state and the new state of companies with one less and then it updates the store but the thing about sharing code in this picture that's really useful and anyone who now listens to this piece of state will be updated is that you drag all that logic out of the component you drag the service out of the out of the picture of being injected in the component and you just say hey just delete this company and dispatch in action so things get much easier for sharing that ngrick State across these apps alright so the way I'd use it I'd do something like this I'll just inject the store into the constructor of a component and then if I want to do something like login are just dispatch in action with a type of login and the object that I've got with the username and password so you can see how easy this component is because all the logic is somewhere else all the injected service you don't end up with six services injected in here alright so then if I want to select the state then it's just as simple I inject the store and then I just go this dot store dot select past the selector in this case it's obfuscated a bit with get user here and then I get the information from the store so this is great for being able to take all your logic out of your components you can go watch a longer version of me hock on about the beginnings of ngrick so if you want I got a play-by-play on Pluralsight about it but just a brief introduction today so we use a lot of njx been using it for over a year now is one of the more kind of some of the first people to use it and now it's kind of more mainstream a lot of teams using it but this NPM packages what's that look like Oh another play-by-play on that actually because today's really kind of a story I'm not going to dive in on how to set this up I'm just going to show you the basics so if you actually want to go step by step through any of these things I actually have a couple of courses on it so this is what I want to do I want to make an NPM package and I want to take the services and the state management out of it so I use it generator because remember I told you it's a pain in that like you have to make it a OT compatible you have to have typed definitions you want to think about closure you use this library and it takes care of everything for you this is the most popular one at the moment and I've used it several times it's quite good so to yeoman generator if you've ever used yeoman it's like a pack of application starter - and you can basically MPM install it on your machine so you basically just go hey yo it will say which project starter do you want to use I want to use the angular - starter and then you give it some details your name your repo the name of the project mine's really original sample and then which testing framework it's quite robust and then basically it makes you a project and if you've done angular before these things are going to look really simple the challenge is not so much understanding the angular bits the challenges you know the NPM package bit so it gives you a source folder with a bunch of samples in it and this index ts file and in there you re export all of the things that you want to be shared out of this NPM package and usually you do that as an angular module so if you've got a lot of you will have seen angular modules they look like this they're a decorator sitting on top of a class with some metadata in them and here it's basically saying I want to export from this module from this NPM package the sample component and then down here for services in angular there it's a bit different I want to register this sample service in the consumer of this module so this is my module in my NPM package and when I consume it in an angular application or an ionic application go register this service so it looks very similar to what you used to as an angular developer you're basically just making modules and then when you want to consume it in the project that wants this code you basically just npm install the package that you've made and I'll talk about where from and then basically you register it like any other angular module sample module for up here in the consuming module so this side of it's really easy the tricky bit is the dev workflow and the configuring to get your package set up and where are you going to host it and all those sorts of things so when you're in your dev machine you'd use NPM link so you have that angular 2 library you've generated with yeoman and inside of there you run a command that will build it for you ready to to send to NPM but when you're in your dev machine you don't want to send it up to to a repository and then pull it back down into your project you want to be able to just go straight into your project and check that it's working so you run an NPM link inside of the the library you want to share and then you see it into the application where you want to use it and then you run NPM link and the name of the library you want to link to and NPM will manage that link for you and then you can update both at once and they'll stay in sync without having to go npm install all the time so that's pretty good but it can be a bit flaky and I've seen lots of teams struggle with it and it takes you time to get used to it and this is really the pain this this and where do you host it and everything that slows teams down with doing NPM packages because most of the code that I'm sharing here is not some you know build wants logging tool and then just leave it alone it's like stuff that you're constantly changing like your auth module and your login page and you get users and show a list of my entities this stuff that's always changing and it's just it's painful to always be building it over here and then building it again in your project and then checking it it's nice when they're all in one place but for libraries don't change too much as I show you then it can be quite good so where do you NPM if you do this in the other project and then you need to NPM install it so the angular 2 library yeoman generator easy to use when you finish you go generate it for me is even a command to send it to NPM but where do you end can install it from well you could use a hosted package manager like NPM we've done that that's nice it's the easiest you're going to be paying you know less than a hundred dollars probably per a month to get it up there for a bigger team but then cheaper for smaller teams but then you could use your own private repository like Verducci i've seen several teams use that they have their own hosted kind of repository on-premise and then they keep it all locked down that works all right and you can even install it just straight from a github repo so you can just use a URL straight to a repository and then npm install it from there this one kind of sucks versioning is harder and it's just not you know as robust as the others so I've done this one several times and I'll talk about in a second where I've gone from here but why do I like it the main thing I like this if it's if you need it versioned I worked with the government project and they were like there is no way I'm going to share my dependencies across my teams and someone else's team we're so separate the teams are so big that if I have to have the same dependencies if I have to always be on one version of this shared code it's too hard they were only going to update when they I can't just ship it out and we all get updated so if you need versioned packages of your code then this is definitely the way to go NPM packages if you have a stable code that's not changing what you've built it maybe it was actually part of an angular app and then you've abstract Edyta it's never gonna change for ages then I also like this approach it's simple it's out of the way it's shareable if it needs to be public this other approach I show you it's one repository all shared in one codebase and if you want to have a tiny piece of that be public and something else be private can't really do that you know that the code that you make in one repos private so this would also be a vote where you might do an NPM package versus having it all in one one repository all right needs more tests and it takes longer to configure you definitely need more tests because you don't know the person consuming it is it gonna work not as well if it's in the same project built by the same build tools then it's easier more time to configure definitely I've seen several teams burn half a week to a week for one developer just to get everybody up to speed so not that big of a commitment it's still a bit of time an IOT sucks this whole ahead of time compilation thing if you need to you know you're just going to have to run our T if you want a small angular application when you go to build it use the tools the CLI you go ng build - - prod and it crushes it down into the smallest app possible and part of that process is IOT or ahead of time compilation you take your templates you pre compile them on your machine and then turn them into executable JavaScript so DIF kilobytes megabytes like I said this is a real pain when you've got a different build tool in a different setting building it and if you go too many days or hours without running a OT on it and you've installed four other libraries and done lots of dev then all of a sudden IOT breaks which it does all the time and then you're like oh which thing broke so make sure you my tip is just run IOT all the time if you're going down this approach and then you just don't run into that problem a little slower to build but then you don't have this issue so I've done this lots actually like this NPM package thing works quite well and then you can share between the two but like I said more recently this whole NX workspace stuff has come around who's heard of now all extensions to people okay so not many people in the room have heard of it who's heard of the angular CLI again almost everybody okay so it's easy to understand what it does it's like basically it's the angular CLI extended so it's now all extensions for angular so now all as a team and they produce this tool and it's basically an angular CLI on steroids so it's not anything new or crazy it's just extra commands that scaffold extra stuff for you to allow you to have multiple projects in one angular application all right it's made by these guys they're now all half of them from the angular core team they left made their own consulting company this is an important thing for me because any new tools I don't trust but these guys wrote most a lot of angular like the dependency injection and the router and things like that and they configure libraries all day long that's what they do at Google and now they have a consulting company they do enterprise angular and then like angular CLI is great but we want more stuff so they've gone and written an extension to it and basically this approach I'm showing you would be not using NPM packages but using that okay so here's a really rough example of what it would look like you would have two applications you could have as many as you want they're all inside the same mono repo so one repository one package JSON one node modules folder so it's a part of a deal of it one repo and then you have say a sample - web application and a sample - mobile application and then you would have libs so it's all about having multiple angular apps and then these libs of the way that you share code so you make multiple libs and compose them together for each application and that's how you make your apps so your apps are really just become more like skeletons and you just import all these libs which are angular modules so you might have libs that are specific just for those apps like sample - web libs like layout and then sample - mobile libs which will just have the pieces of code that are just for that library or just that app but then you'll have a whole bunch of reusable ones like this and then they can be shared across everywhere so I really really like this I've done lots of angular projects and I've done lots of team-based ones and lots of sharing across code and I've been using this now for a couple of months it's very new still but it's been great I've got a project that is soon to be in production we've been using with it I ran a workshop here on it recently it's it's something I'm very excited about even if I'm not doing mobile even if I was doing one angular application because it's opinionated and if you just follow it you're going to avoid probably 90% of the mistakes you could make choosing how to scaffold a project and on top of that your team don't have to spend weeks deciding on best practices and researching so big fan alright this how you make it you basically npm install the angular CLI globally and the narwhal extensions globally globally and then you just run create NX workspace and give it a name so it's just really an extension to the CLI that's something to remember and for me it's something that I keep forgetting and I talk with the guys who make it my friend Justin's one of the people on the team and he always goes Duncan the thing that you you keep you come to me with these problems and you forget that you know all it is an extension to the CLI if I have a problem it's not a Duncan problem or a custom problem or an NX problem it's more a CLI problem or an angular module problem so really don't think of it as something too new it's just an extension to the CLI so it makes you this and you can see straight away if you've seen an angular CLI project it's different in angular CLI project you just have one app folder here you've got an apps folder and a libs folder so you put multiple apps in the apps folder and all the shared code goes in libs in the libs folder not many people are doing this with ionic yet I'll be honest I'm probably one of the few people to do it I've seen people doing it with native script that's like ionic is a guy called Nathan Walker he's got some awesome egghead IO videos worth checking out if you're gonna do the native script version of this but there's this is still really new and ionic is really not built to be used in line with angular's build system yeah ionic has its own build system to compile it for being on the App Store as an IP K or an apk so I stick it in a separate folder called mobile apps because I just go what I really want to win from is not writing my code twice and having it be less buggy for that reason and be able to spend more time making better components so I really just want to get the benefit of this in the mobile app the ionic app just for those libs so I'm happy to say I'll cut my losses I'm gonna stick it in its own folder and it's its own build system inside of that folder in the same repository but all of the the big benefit is the libs so the build system all the benefits I get out of NX like NX will run tests across all of your apps at once and know when things have changed across your app for your build tools and stuff but you lose that in this approach but it's easier than the NPM packages so inside your leads you end up with these sub directories again so here I've got a sample app example or shared for all the things I'm gonna share an estate folder in the libs folder for all the different pieces of state because in NGO X you'll have slices of state or Lib users entity bla entity bar so forth so here are this earth one I make it just like I'm writing angular this isn't the hard part of sharing code when your share code you're just writing angular modules and once you can write an angular module you can share it the trick is how do you share it so here I would write it down here in a Lib an annex gives me all these tools for being able to do that and exposing it out to this apps folder and the separate apps so when I want to get it all I do is I import my annex Lib and you can see here it's namespace this annex Lib it said import Earth module from at sample slash state slash auth and if we go back here you can see the folder structure is Lib slash auth but where does it get this at sample from so this is like a name spacing that it does otherwise would be like dot dot slash dot slash dot dot slash Lib slash state slash auth so here you've got this name spacing so this is an example of how it annex kind of wraps everything up and helps you have a system for doing this so I import it here and then when I want to use it I just use it like any module that I've written in angular I just say read I just register my own X live by saying author mod dot for route so it's no different than using the NPM packages the difference really is you know where do you build it do you build it in this separate thing in an NPM package and then after version it and put it up there and bring it back down and go through this dev cycle or do you build it right there in the same folder and the same up in the same repository and take all that out of it all right so I've I've done an interview with Justin on this on my blog Duncan anaconda if you want to learn more about it they're also starting to pump out a lot of content on it I think it's going to be a pretty big thing this year annex for the angular world because it's not hard to use it's just an extension of the CLI I think they also just did a interview I know they just did an interview on angular air as well so you'll start to hear a lot more about this NX stuff so why do I like it why why would I go and quit my job start my own project put my own dollars and then decide to use an X well it's going to be much faster to configure a project I don't have to go get this yeoman generator and teach the guys who are working with me on this project how to use it I just NX install make me a new project and it's ready to go it's much faster to integrate my shared code as well like when I'm actually doing my development I don't have this NPM linking another developer doesn't have to wait to get it it it's all in the same repository it's all there all the time shared dependencies I'm going to call this a plus and a minus like I said before you're not gonna have any versions it's a mono repo so you've just got one version of your repository and these libs aren't versioned so if you've got two apps and they need only one of them in one's managed by one team and ones managed by another team and team 2 is not ready to pull in your new version of your Lib well then you know that's a challenge what do you do because in this approach everyone has to update all the time but on a flip side of that you're only gonna have one version of everything so you won't open up your project and go oh we've got we'll open up this project and then this project and then this repo and see that you've got three versions of typescript and you're like well they can't use my new the up anyway because their version of typescript is different and then why is you've got three projects sharing code with three versions of typescript and so forth so this is a problem but it solves the problem by enforcing that you're on one version of everything all right build tool is another big lesson we're learning this at the moment classically we make a back-end project and front-end project and we deploy them separately and then when we make another front-end project we do play that separately and it's a separate repository for everything so build is really easy you just build one thing at a time but in this case you're going to build everything at once so when I say moderator people go oh do I put my back-end in here as well my current project we're using server lists so yes we put all our functions in there as well and we build that at the same time but you don't have to and you don't have to put all of your angular apps in here you could say these two angular apps are going to be showing so much code let's make one repository or them but our other five angular applications our company have let's stick that in a different repository and not use NX we you don't have to put doesn't have to be a huge monetary perk could just be a mini one you could just have one angular app so the build size is also you know a bit of a challenge there but it's also a positive because when you build your angular app you also build your libs and you know they're going to work together and all the tests run at once so it's also much faster and easier to update stuff because you don't have to wonder if it's going to break the consuming application so you can see I'm biased yeah I'm kind of betting on this one and really liked it but that's because I'm able to not have to have versions of these packages but let's just say my project gets more robust in the next six months and I have some things that aren't changing and I want to make them shareable to the public because they're in this private repository I can they're just angular modules I could suck them out use the angular 2 library and turn them into NPM packages and have a combination of a mono repo and some NPM installed packages okay so where to from here where do I think we're going to be going with this sharing code stuff with angular because there's one big pain point at the moment with doing ionic and angular is that these component I can't take my components that I'm writing for this web app at the moment that are all in angular material so it's an angular material toolbar and an angular material list and a material card and all these HTML elements and I can't take them and put them in my mobile app so I've got all these duplicated like kind of features across both of them and I'd really love to have the exact same HTML across both so if I have a list on my mobile I want to use the same HTML for its same component presentational component in the web but the web will obviously just expand responsively to have that list wider but it same code but you can't quite do that just yet but ionic are really interesting and they're betting the world on web components so they've just yesterday released their first stencil app demo application for making pwace or progressive web apps and it's got or you can already use all of their ionic components as web components there's no documentation it's a bit clunky and difficult to figure out the exact syntax but it's coming it's like really soon an ionic 4 is going to be based on this so pretend I think this year we'll see that a project like mine where I'm trying to share across these two I'll use these stencil components from ionic that are pre-built like I'd use with material on my web apps as well and then I'll actually also share all of the markup across my mobile and web and I'll get who knows maybe like 90 percent code reuse across the two but at the moment I don't want to mess around with it the project's got to get done so I'm just going to use material on my web application and wait until I own it could get a bit closer to to something that's production-ready I'm going to be in Minnesota for the next NDC or the next next NDC because there's one in Copenhagen and I'm gonna run a workshop pretty much on all these things some of the guys here came along to my workshop this week on this topic of NX and n Derrick's so if you want to come along and join me please do and in summer we had a look at it angular and ionic what's new we looked at some code reuse options and how it's not as simple as copy and paste you really need some sort of tool to help you with it we looked at how in grx is not just great for enterprise and dealing with state but you know sucking that logic out and then we looked at the two options around NPM packages and and mono repos so hopefully I've inspired you guys to go have a play with some of these tools this is how you can get a handle on me on Twitter I just leave my direct messages open if you want to just direct message me feel free and I'm gonna hang out after this offstage so if you want to ask any questions feel free to to grab me thanks guys [Applause]