AngularJS Architecture: Edit and Create Bookmark States
In this lesson, we continue to dig into ui-router while doing some significant refactoring to our Eggly application.
We will start out by removing MainCtrl entirely from the application as we start to move functionality to more appropriate places with the application. We will build out the edit and create sub-modules to include the states and controllers for editing and creating a bookmark. With our states defined, will leverage them to manage our view instead of the ng-if statements we were previously using. We tie it all together by using CategoriesModel to track the current category and provide functionality to the BookmarksListCtrl.
We cover a lot of material in this lesson as we start to apply the concepts covered previously to finalize functionality in the application.
Shaun, great content. An architecture / best practice question. With ui-router do you always require one parent with sub nested views or can you have two parents withs ome sort of relationship? Example, could you have 2 categories (not that it would make sense, but for illustration purposes) one for vertical tabs and one for horizontals tabs / states. Left tab would filter subject matter by topic whereas lets say the top categories filters by roles / groups using the bookmarks. So I could end up with sub matter development clicked on left and registered users on top and the result would be the correlation of the two axis in the matrix.
lol and when I say Shaun, I meant Lukas ... apologies.
The code which is available in github is not in sync with the video. In github all the controllers are used as MainCtrl as main and all reference of scope has been changed to main.*. However in the Video it is still showing the old code. Though the code in github is latest and better practise but the same is not captured in the video. I had some tough time in understanding that and had to jump out of the course and watched / read other material to understand.
For the ui router architecture the state's are moved out of the main.js and into they're respective controllers and configured there. I was just wondering if this is the best practice, so that I may continue to do it this way. Thanks!
Also, noticed that the service is written inside of the model, is this also best practice?
@Tim,
About states: yes we really like this approach because it keeps the logic for a particular feature grouped within that feature. It is also congruent with the Angular's implementation of a component, both in Angular 1 and 2.
About services: this isn't so much a best practice as it is a convenient naming convention. We used the model naming convention simply because the service is basically modeling a particular entity (categories or bookmarks). If the service had been handling something like authentication, we would not have used the model naming convention.