AngularJS Architecture: Review
In this lesson, we review the high level concepts that we covered over the course of this series including file structure, sub-modules, data models, ui-router and animations.
[00:01] Now that we have completed the Eggly architecture series, I wanted to take a moment to review the key concepts that we covered over the course of this series.
[00:16] When we started the application, we had all of this layout in a single HTML page. As well as we had this large, monolithic main controller in the Eggly-app.js. Over the course of this series, we started to break that out and refactor it into meaningful and specific places and pieces of code.
[00:42] We created a file structure that reflected the entities that existed within the Eggly application, the main two entities being categories and bookmarks. We created a categories folder and within that, we put a bookmarks directory because we are creating and editing a bookmark. Each one of those requires a separate controller and view. We created a directory for those as well.
[01:09] Once we had the file structure in place, we started to build out sub-modules. We started with the main Eggly module and then from here we introduced the categories module. Then we introduced the categories.bookmarks module and built it all the way out to create and edit.
[01:30] With the sub-modules in place we also introduced the concept of promoting data to models. We took out the local data within the main controller and promoted it to a bookmarks model and a categories model where we talked about some different strategies for retrieving the data, caching the data, and performing business logic.
[01:55] From here, we introduced UIrouter and started to build out states to navigate from the different states or routes in our Eggly application. We started out with a very basic, abstract Eggly route that is a placeholder for all of the rest of our routes within the application. Then we defined our categories route with two named views. Categories targeting the categories UI view and the bookmarks named route targeting the UI view named bookmarks.
[02:30] Then we also created a unique route for the state where you have actually a category selected to show just the bookmarks for that category in Eggly.categories.bookmarks. Then we created a create and edit state as well for editing and creating a bookmark.
[02:52] Once those were in place and we were able to navigate to the specific places within the application, we needed to go back and wire up the functionality we introduced in the first app into our new app.
[03:07] We set up the ability to create a bookmark, edit a bookmark, and delete a bookmark. Once those were completed, we finished things off with a fun animation to animate between UIrouter state changes. In about 20 lines of code, we were able to add in a really nice transition and end up with a much nicer, cleaner extensible version of the Eggly application.
[03:37] Thank you for joining me for this series. It's been a lot of fun. I look forward to seeing you in further videos.
For these lessons on my app, this line always return undefined when you refresh the page. On the off chance that a user would do this, how can I fix this.
model.getCategories = function() { //console.log(categories) always returns undefined return (categories) ? $q.when(categories) : $http.get(URLS.FETCH).then(cacheCategories); };
@Tim, if you want data to persist through a page refresh, the best solution is to use cookies or local storage (or both!). The module we like to recommend for this is Auth0's angular-storage module found at https://github.com/auth0/angular-storage. Once you get that set up, you can add a method call inside of cacheCategories that not only caches them in memory but also in cookies/local storage. Hope this helps!
Lukas, You are a fantastic teacher. Really good series. Many thanks. Paul
@Paul Thanks! Totally made my day! #highFive
First—Love this series! Thank you to everyone who made this possible, especially Lukas.
I created a test application along with these lessons for an imaginary clothing store. I created one master JSON object, so the whole db can be loaded and cached using only one http request:
data : { shirts : [{id:1,name:'Shirt One'},{id:2,name:'Shirt Two'}] pants : [{id:1,name:'Pants One'},{id:2,name:'Pants One'}] shoes : [{id:1,name:'Shoes One'},{id:2,name:'Shoes Two'}] }
And I'm using a 3 column layout:
Categories nav | Collection list | Model view
Shirts* ( active ) | Shirt One* | Shirt One Pants | Shirt Two | Details… Shoes | |
Using the data models from the series, I load the JSON and cache it, but 3 $http requests get fired on page load because all 3 views need access to the data that isn't cached yet.
I solved this by using resolve in the parent $state config to resolve the data before any view is activated.
The only other way I found to do this was to use $scope inheritance and $watch the parent scope for the data, but this felt very messy.
Is resolve the only clean solution in this situation or did I miss something?
Thank you!