Since the beginning of the course we've been taught several staples of modern web development, including the use of a clearly separated back end and front end, and the use of an MVC (Model View Controller) structure has been a large part of that. This week however we've been introduced to AngularJS, and while I wouldn't say that it disregards those staples, it certainly behaves in ways that test our assumptions.
I've used the phrase MVC above without explanation, so here we go. Following a Model View Controller pattern, as does Rails that we learned last week, the structure of the web app can be largely split across the three categories. The Model manages the data and logic of the web app. The View refers to a representation of information, usually the visible part of the site. The Controller deals with input, assesses it and passes it to either the Model or the View. That's a hugely simplified description.
AngularJS is a framework which unusually places a lot of what is traditionally considered back end logic on to the front end, causing us to reconsider what we'd previously believed to be fairly rigid constraints on what each end of the stack should do. Angular (I'm hereby dropping the JS because: hassle) does address the concepts of Views and Controllers, only that it approaches them differently from how a traditional MVC environment would. Angular has proven difficult to categorise alongside traditional MVC frameworks, so is generally considered a MVW (Model View Whatever) framework. In other words, call it what you want.
The concept behind Angular's initial development was to redesign ‘HTML the way it should be'. When working with Angular, logic is placed inside Angular controllers, or extracted into separate entities called factories, services and providers, which largely all do the same thing with slight differences. The logic is then implemented by attaching what Angular calls directives to specific HTML elements within the views, creating what is known as 2-way data binding. 2-way data binding means that any changes to the controller are immediately reflected within the view without the need to refresh the page, and likewise updates within the views are immediately propagated to the controllers.
GitHub profile viewer
Our week with Angular felt like a very brief crash course. We were allocated only Monday and Tuesday to learn the basics by following an official Google tutorial while keeping particular questions posed by Makers Academy in mind. From Wednesday onwards we were then split into groups to work on a small scale Angular project. The project task was to build a GitHub profile viewer, an application that acts as a search engine of GitHub users by polling the GitHub API for data. In my opinion this project was perfectly sized for the given amount of time. As a group we did manage to implement most of the intended features, although we ran out of time to apply the finishing touches we'd have liked, perhaps another day or two would have afforded us the opportunity to get the project to a point we would consider complete.
Angular makes it relatively easy to get an application up and running quickly, and it didn't take long to have our local dummy data (as opposed to data actually pulled from GitHub) displayed within our views. Surprisingly working with the GitHub API to fetch the real data was actually the most difficult challenge for our group. Ideally we'd have liked to request from the GitHub API the data for all members of a given GitHub organisation (the Makers Academy organisation in our example) and be returned the entire list in JSON format. However this isn't quite so simple due to a combination of factors. For one thing, when polling the API we were initially acting as an unauthorised user, which confusingly only returned the data for a small handful of members, only 24 of the total 647 members at the time were returned to us to be exact. After some investigation we discovered that the 24 members which we were receiving were those 24 who had at some point in time opted to change their Makers Academy organisation status from the default ‘private' setting to ‘public'. I suspect they probably all did so simply for the same challenge that we were currently facing.
This week we were given no weekend challenge, but were instead afforded the extra time to work on our week's project. For this week's relatively small scale project this enabled us to begin working on the front end visual design, something which is generally overlooked on the Makers Academy course, but which I'm always keen to work with. However the primary focus for this week was Angular, and I believe that this project provided us with a solid introduction. I leave this week appreciating the concept of Angular, but with many questions regarding the ways in which it differs to the technologies we've previously used. As with pretty much everything that this course introduces us to, a lot of self study is required before I could begin to feel comfortable with it.