#100DaysOfCode - Day 42: Angular-material Autocomplete

Today, I’ve mostly been working on some AngularJS stuff. At work, there’s not enough meaningful to post about, so I wanted to dive into what AngularJS things I’m doing right now on my blog.

For starts, I wanted to talk about the two technologies I’m using for this blog, how they conflict, and how I’m resolivng that conflict.

A. Jekyll - a file generating software

This blog has always been based on Jekyll, which essentially uses a language called Ruby, to interpret a bunch of template files that then get rendered into HTML (the front-end stuff you see), from Markdown (guide).

Jekyll is a tool that mostly has its own syntax:

• Double {{ }} tags to access variables, such as the name of this post when I created the post template:

  <h1>{{ page.title }}</h1>
  

• {% %} to add files, or do more sophisicated functions, like if statements or looping

  • {% include googletagmanager_head.htm %} <– Adding google tag manager’s script tag into the template

  • If statement (decides when to show next/previous links on blog posts)

{%  if page.previous.url %}
  <a class="prev" href="{{page.previous.url}}">&laquo; {{page.previous.title}}</a>
{%  endif %}
{%  if page.next.url %}
  <a class="next" href="{{page.next.url}}">{{page.next.title}} &raquo;</a>
{%  endif %}
```html

  - Loop through my posts and display them like [here](/posts)
  
  ```html
  {%  for post in site.posts %}
  <li>
    <span> {{ post.date | date_to_string }}</span> » <a href="{{ post.url }}" title="{{ post.title }}">{{ post.title }}</a>
  </li>
  {%  endfor %}

In terms of how it makes connections between everything, it uses a technology called Kramdown (which is amazing), that interprets my markdown, and compiles every single file into a bunch of different HTML files, which ultimately have the same code, repeated from page-to-page. So, when you navigate through my blog, the menu looks the same, but it’s technically a new page and you reload that menu again, because that same menu code exists in every. single. file. for every. single. page.

This isn’t a problem for a small blog like mine, but for a big application that has a lot in posts, we should really only require you to reload the code within the post (and not all the menus and such surrounding the post).

So, why don’t I do that? Well, because it’s not built in (Enter: AngularJS).

B. AngularJS

AngularJS is a front-end framework that was built to help turn static sites (like Jekyll static text generators) into “Single Page applications”, so that it uses a browser-based language called javascript to decide what HTML files to load and when. The great part about AngularJS is that you can decide to only load small components of the entire application, so I could decide to just load my blog post within the current page, without all that extra stuff.

Since my wife is calling me to bed, I’ll have to refrain from diving too far into depth with AngularJS, but just know that it can do a lot of handling on the front-end to make the amount of files/content you load in your browser much smaller.

Unfortunately, AngularJS does have a conflict with AngularJS, in that it also uses the double squiggly {{ }} notation to access variables (but, in this case, AngularJS, not Jekyll, variables). Well, AngularJS developers have thought of this being a possible issues with conflicting tools, so they introduced a way to get around it by changing the symbol. By changing this on the site’s angularJS app, I’m now able to properly use AngularJS within this app:

And below, will be some embedded angularJS loading within a markdown blog post, using a particular bracket notation.