Month: September 2017

Projects 3 and 4 of my Speedrun challenge are now functional. You can find the code to the four front end projects I’ve completed so far in this GitHub repo.

As I’ve stated before, for the sake of time I’m holding off on styling the apps until the end, so these Local Weather and Wikipedia Viewer apps are pretty ugly. They do, however, function properly, which is all I’m looking for right now.

What I learned

The Weather and Wikipedia projects provided more repetition in making HTTP calls using Angular. Both projects require the use of an API call in which fairly large JSON objects are returned. Working through the two projects helped solidify my ability in handling such calls and rendering the relevant results.

Biggest Challenge

I think the biggest obstacle I had to face with these two projects (other than putting together an API link to Wiki that actually worked) was rendering the results of the Wiki API.

For each query to the Wiki page, you’ll receive an object that contains (potentially) multiple responses that you need to render in the HTML page. In Angular, this immediately makes you think of the *ngFor directive, but that will only work for objects that are iterable.

If I query the Wiki Viewer for the word “fire”, the following object is returned:

You can see that Response.query.pages contains 10 objects that we need access to in our HTML. As this object is not iterable and at the moment (as far as I know) Angular does not provide an option for iterating over objects, we need to figure out a way to iterate over the object.

It’s possible to reformat the results into an array, but it would be easier to use a pipe (see this stackoverflow answer).

The following function will return an array of keys to the object ‘this.results’.

You can see when we set

 and we run it with the same example as above, ‘fire’, we get an array of keys to the pages object:

We can now use the keys() function to iterate over the object we want to access in our HTML using *ngFor

That’s it! I’m on to my next project….

-Jeremy

This is an update to my Chingu Speedrun Challenge. If you don’t know what the hell I’m talking about, it’s explained here.

The Speedrun Challenge is all about repetition and iteration so that something new becomes second nature. This post covers the second project, the Quotes app, which should be the first of several projects that will focus on making and handling API calls in Angular.

I’m off to a slower start than expected in my Speedrun for two reasons. Actually three reasons, but I don’t plan on ‘fixing’ time spent taking my kids to baseball and football, I’ll just have to work around that…

The two causes for the slow start that I can address are A) being overly nit picky about the design of each project (Tribute Page) and B) diving down deep rabbit holes (Quote Project).

Hold off on Design until the End

The first issue (design) I plan on addressing by not styling any of my projects until the end. I’ll focus instead on getting as many functional apps built as possible. At the end, I will style the collection of apps as a whole as much as possible before addressing them individually.

Each project will have a minimum level of styling that is essential to the functionality of the app. I will attempt to keep the styling to the level of functionality and not get stuck in the weeds on the little things.

Avoid Rabbit Holes

The second issue (rabbit holes) will be harder to fix.

While I was building out the Quotes App, I got stuck focusing on how to cast an observable to a custom type. I had a working API call fairly quickly, using the https://talaikis.com/api/quotes API (this API returns 100 quotes so I could limit the HTTP calls).

It’s my nature, however, to dig deeper when I don’t fully understand something. Here, I was having a hard time understanding the best practice in Angular for taking the Observable that is returned from the HTTP call and converting it to a custom type.

This led me down a rabbit hole looking into observables, classes, interfaces, reading more on Typescript, etc, etc.. While this was definitely helpful, and I learned quite a bit, I have to keep in mind that the Speedrun is mostly about tackling as many projects as possible.

Moving forward, I’ll try to make a conscious effort to limit my research to gaining a working knowledge of a topic, then move on. This will be difficult, as I have a habit of digging deep into topics that I don’t completely understand. For these instances, I’ll keep a list of topics to research further after the Speedrun ends.

You can find the code for the Quotes App here. I’ll be working on the Local Weather App next.

Earlier this year I was fortunate enough to discover, and become part of, the Chingu Cohorts.

Here’s a medium article on what the Chingu Cohorts are, but suffice to say that it’s an online (Slack) community of individuals determined to be the best developers they can be and help each other along the way. It’s a place for learning, building, collaborating and motivating, and I feel lucky to have found it.

 

Recently, a group of Chingus started a Speedrun Challenge, which is basically up to a month spent building as many of the Free Code Camp (FCC) projects as possible to learn and master a particular stack. You can learn more about the Speedrun Challenge in this Medium article and this GitHub repo.

I’m starting a Speedrun today and will be working with the MEAN stack. Part of the Speedrun Challenge is to write a blog or Medium post for each project completed. This is my post for the Tribute Page.

Given that the Tribute Page is the first ‘Basic Development Project’ in FCC, it’ll be a very basic project consisting of one static page paying tribute to someone or something. To speed things up, I’ll be reusing the content from my original tribute to Thomas Edison.

Project Structure

The final part of the Challenge is to create one single page application (SPA) out of all the projects that you’ve created. With this in mind, I’ll be building all the individual FCC projects as one larger application with a single landing page.

I created the project using the Angular CLI by running the following code in the VS Code terminal (View->Integrated Terminal):

This sets up a project called “fcc-portfolio” in the current terminal directory. The various flags do the following:

• --prefix fp  will prefix all the the component selectors with “fp” (default: app)
• --routing  will generate a routing module (default: false)
• --style=scss  will set the style file extensions to scss (default: css)
• --source-dir=client  will name the source directory ‘client’ (default: src)

Big thanks to P1xt for pointing out the bottom 3 flags listed above. They definitely saved me some time setting up routing and Sass.

Once the project was up and going, it was quite easy to add the Tribute page using my previous project as a guide for content.

 

Currently, I have the app.component acting mostly as the <router-outlet> with the router serving up the LandingComponent and the TributeComponent as called for.

The LandingComponent will continue to act as the main landing page with links to all the various projects.

You can follow my code in this GitHub repo.

Biggest Challenge

For me, the biggest challenge here was design and making the page responsive. Maybe challenge is the wrong word… It’s certainly where I spent most of my time.

I’m fairly new to working with CSS Grid and Sass, so incorporating those and making the page fully responsive took more time than it should have. But hey, isn’t that why I’m doing this??

You can see the final product above. I’ve decided to call this good enough for the time being (with respect to design) and move on. I’ll come back in the end and work on getting the design to look consistent throughout all projects.

Alright, off to my next project.

-Jeremy