I was thinking recently about how intimidated I was by error messages when I first began to program. As soon as red text appeared in the browser console or terminal I would begin to feel a little panicked. My heart rate would rise in proportion to the length of the stack trace. But somewhere along the way that intimidation just began to vanish.

The change started when I actually stopped to read and attempted to make sense of the errors instead of blindly trying things until they went away. I began to think of the computer more as a non native speaker trying to communicate with only a few rehearsed phrases at its disposal and less like an evil being whose sole enjoyment in life is giving me unsolvable riddles in cryptic and impenetrable language.

It’s trying to tell you that something went wrong, but it can only choose from a few pre-programmed messages. The good news is computers are logical. They will never tell you something is wrong for no reason. Although sometimes it seems like they do. The bad news is that means it’s always your fault.

It’s true. Undefined really isn’t a function.

The next time you see an error message don’t recoil in fear. Instead, read the error message, follow the stack trace, and try to decipher exactly what it is telling you. The more you do this the better you’ll become at interpreting what the computer is actually trying to tell you.

Customization

react-calendario takes advantage of the powerful Render Prop pattern allowing the consumer to customize and style the calendar or date picker however they like. Unlike passing configuration props to traditional components or the Higher Order Component pattern the Render Prop pattern allows the consumer of the component to customize and style the JSX returned by a component however they like.

react-calendario expects a function that returns JSX either as a prop named render or as its only child. react-calendario calls the provided function in its own render method passing to it all the necessary logic to create the calendar or date picker component as arguments.

You can read more about the arguments passed to the function here.

Internationalization

I am particularly excited about react-calendario’s support for Internationalization. Using the Intl.DateTimeFormat API react-calendario can support all the languages supported by a user’s browser. To configure the language react-calendario will use just pass a supported browser language code as the language prop. If the language code is invalid or absent, react-calendario will fallback to the browser’s language.

Inspiration

The inspiration for using the Render Prop pattern as well as the layout of react-calendario’s README were inspired by the awesome work done by Kent C. Dodds and others on downshift. Keep up the great work!

ifTrue ? 'I am true' : 'I am false';

Umm… what is that? That, my friend, is the conditional operator, or a ternary. So named because it is made up of 3 parts. The three parts are: the condition to be checked, the expression to be returned when the condition is true, and the expression to be returned when the condition is false.

The ternary is an analog to the if/else statement with the only difference being a ternary is an expression, while an if/else block is a statement. Okay. What exactly is the difference between an expression and a statement?

Expressions vs Statements

An expression is any piece of code that evaluates to a value.

A statement is essentially a series of actions for a program to perform that does not evaluate to a value. Think of an loop or a conditional statement.

The key here is that expressions have to evaluate to a value, while statements never do.

This is clearly illustrated by comparing what happens when setting a variable to the result of a statement vs an expression. In the following example num will have the value 2 after the expression 1 + 1 is evaluated.

var num = 1 + 1;

Whereas the following will throw an error of unexpected token and your editor will most likely alert you that a statement was found where an expression was expected. This is because an if/else block does not evaluate to a value.

var a = if (true) 1 + 1
  else 2 + 2;

Setting variables

One simple use case for ternaries is setting a variable’s value based on a condition. Without a ternary you would have to do something like this to conditionally set a variable.

var num;

if (someFlag) {
  num = 4;
} else {
  num = 42;
}

This could be condensed slightly by removing the curly braces.

var num;

if (someFlag) num = 4;
else num = 42;

Even that is less than ideal. Instead we can use a ternary to check the flag and return the number we want from our expression. That would look something like this.

var num = someFlag ? 4 : 42;

Conditional function arguments

JavaScript does not allow you to write statements inside of the parens of a function call. In order to pass different arguments to a function depending on some condtition, a similar method to the one used above could be used. A variable could be set using if/else statements and then passed to the function.

A cleaner, more concise, and easier to follow method would be to use a ternary to pass the argument.

someFunctionCall(
  someCondition ? 4 : 42
);

Returning expressions from functions

The most beneficial place to use a ternary is in the return expression of a function. The reason being that it helps you avoid errors.

What is the potential error in the following example?

function capitalize(string) {
  if (string.length) {
    return string[0].toUpperCase() + string.slice(1);
  }
}

It’s subtle and might not seem like a big deal, but if someone were to call the function above with an empty string the function would return undefined. Which would really wreck someone’s day if they were chaining this function together with others.

This is because all functions in JavaScript return undefined unless they have an explicit return. That is the return keyword with an expression afterward.

So, the issue here is that there is an if statement but no else case. This is precisely why a ternary is so handy when conditionally returning a value from a function.

Remember, a ternary is made up of 3 parts. It needs all of those parts to be a valid expression. Therefore, when writing a ternary, the developer is forced to deal with the else case.

function capitalize(string) {
  return string.length
    ? string[0].toUpperCase() + string.slice(1)
    : string;
}

The next time you find yourself wanting to write an if statement to determine what to return from a function, just go ahead and use a ternary instead.

Truthy vs Falsy

In JavaScript all values that are not "", undefined,null,0,NaN, and, of course,falseare considered true when evaluated as a boolean, that is placed in anif conditional.

For example the following will evaluate to true and the statement will be logged to the console.

if (1) {
  console.log('1 is true.');
}

So, why is this useful? The idea of truthy and falsy can be taken advantage of to write simpler code.

Let’s say you have the following array.

var arr = [1, 2, 3];

If you wanted to do something with the array only if it has elements inside it, you could use a comparison operator like >= to check if the length of the array was greater than or equal to 1.

if (arr.length >= 1) {
  // do stuff
}

This works but can be simplified by checking for a truthy or falsy value. Knowing that any number other than 0 is truthy and that if the array is empty it’s length property will be 0, the if can be rewritten as the follows.

if (arr.length) {
  // do stuff
}

Explicit Boolean Coercion

If you every need to convert a truthy or fasly value to a a boolean you can just add a !! in front of the value. The first ! will convert the value to the opposite of what it was. Adding the second ! will convert the value to a boolean of the same logical value as the original value.

!0; // true
!!0; // false

Registering a service worker

In order to get a service worker to do your bidding, you must first register it with the browser.

if (navigator.serviceWorker) {
  navigator.serviceWorker.register('/serviceWorker.js').then(result => {
    console.log('Service Worker registered!', result);
  });
}

The check for navigator.serviceWorker is necessary because some browsers do not yet support service workers. I’m looking at you Safari.

For up to date info on what browser support check out the service worker page on caniuse.com.

So, service workers are just JS?

Well, not exactly. While you do write the service worker in JavaScript, they behave a bit differently than the JavaScript you’re used to. They run in a separate thread, and they do not have access to the DOM.

Instead, service workers register a series of events to which they want to respond. These events include lifecycle events (install, activate, and download) for the service worker itself as well as fetch events issued by the browser, among others. Registering an event in the service worker should look like pretty standard JavaScript.

Here is a very simple example of registering an event to watch for the service worker’s install event which is called every time a new service worker is downloaded by the browser. Self in the snippet below references the service worker.

self.addEventListener('install', event => {
  console.log('Service Worker was installed!', event);
});

Reliable worker

When you register an event listener for fetch events issued by the browser the service worker effectively becomes a proxy server, a middleman, between the browser and the actually server that hosts the assets you want.

Note that an AJAX request is not the same as a request sent using the Fetch API. Service workers can only intercept requests made using the Fetch API.

You can choose with each request whether to cache the response, or, perhaps, not send the request to the server at all and respond with a previously cached response. You can even load your app without an internet connection by caching the necessary assets when the service worker is installed. This is a technique known as pre-caching the app shell.

Working in the background

Since service workers run as background tasks separate from the thread your normal JavaScript runs in, they are able to listen and respond to events even when the browser is not open.

This enables features such as background sync and push notifications, which allow developers to create more resilient and immersive UIs.

Along with the other technologies, the manifest file allows you to create a web app with performance and experience that rivals that of native apps. Users will be able to install the app on the device’s home screen directly from the web, use the app when offline, and receive push notifications. This will allow companies to focus on building a single app that provides a great experience for web and native users.

Browser Support

At the time of writing, caniuse reports that only Chrome, Chrome for Android, and the Samsung browser support the Web App Manifest. Those three browsers alone provide support for 59% of all internet users.

The other top three browsers, Microsoft Edge, FireFox, and Safari (WebKit) are listed as in development. So, it will only be a matter of time before we see support in those browsers.

As with other features of a Progressive Web App, the lack of browser support is not a deterrent. These features only enhance the experience of users on supported platforms and do not significantly degrade the experience on platforms without support.

What is Nuxt?

Nuxt is a framework for easily creating Universal or Server Rendered apps with Vue. It is inspired by the framework Next from Zeit.

Nuxt also provides the ability to generate a static version of your site. This feature is similar to Jekyll, but allows you to use the full power of Vue and related tools like Vuex and Vue Router as well. The static site generated with Nuxt can be hosted on any static hosting provider; I used Github pages for this site. The Nuxt team uses the same technique to generate their docs.

Integrating Nuxt

First step to integrating Nuxt was to install it in my app with npm install nuxt --save. After installing Nuxt, I had to remove some old dependencies installed with Vue app that were now redundant.

Once the dependencies were straightened out, I needed to create the directory structure Nuxt uses to automatically create routes. This mostly consisted of moving the container component I already had into the layouts directory and moving the components that were acting as pages to the pages directory. All the other components I moved to a new directory called components and imported them as needed into the components in the Nuxt directories.

Configuring Nuxt

By default Nuxt is configured to handle many things for you. Any changes can be added easily by editing the nuxt.config.js.

I used the router property of the Nuxt config to add a class to my active links. I also added the following simple middleware that redirects visitors to the about route from the root of the site.

export default function({ route, redirect }) {
  if (route.path === '/') redirect('/about');
}

Another convenient configuration available in the Nuxt config is the head property. The head property allows you to define the default meta properties for you app. This can be used in combination with the head method Nuxt adds to your components to very simply update the meta tags per page. I use this technique to update the Open Graph meta tags on my journal entries.

Static Site with Nuxt

Generating a static site using Nuxt was pretty straight forward. I only ran into one relatively small and easy to fix issue. Navigating to a journal entry once on the site worked fine, but if you refreshed the page you would get a 404 error. This was because by default Nuxt only generates routes for the root of your static site. If you want to add dynamic routes or routes with dynamic params you have to add a tiny tweak to the config file.

For my site, I wanted to add a dynamic param for each journal entry. That is /journal/:titleOfEntry. Adding the following snippet to my config allowed the desired routes to be generated.

generate: {
  routes() {
    return new Promise(resolve => resolve(journal.map(entry =>
      ({ route: `journal/${entry.data.url}`, payload: entry }))));
  },

The route property in the object above is required and used by Nuxt to generate the dynamic routes. The payload property is optional and is used to provide data to you components during the generation. Any data provided in the payload property is passed to the the asyncData method, which Nuxt adds to your page components and is called when the component is rendered server side or during the static site generation.

Async data is also called just before navigating to the route that renders the page component. Though in this case, it is not provided the payload. An alternative method for getting the data will need to be provided when payload is false. Here is the asyncData method from my journalEntry component.

async asyncData({ payload, params }) {
  return {
    entry: payload
      || journal.find(entry => entry.data.url === params.journalEntry),
  };
},

Conclusion

Overall switching to Nuxt was easy and pretty straightforward. The ability to statically generate your site is very neat feature. An easy to use, static blog framework is just asking to be built on top of Nuxt.

Hmmm… 🤔 Maybe someday.

In the meantime, if I happen to find myself needing a way to render a future project on the server I will definitely be reaching for Nuxt.

Something else that might be familiar is completing your feature preparing, to push your changes, and realizing your 12 commits were made on develop. Now, if you’re anything like me git can still be a little intimidating when trying to fix your errors. Have no fear, though. This particular screw up is very easy to fix.

First, create a feature or bugfix branch from develop. Then, reset develop back to where it should be.

git branch <name-of-new-branch>

# find the sha if you don't already know it.
git log

git reset <SHA-to-go-back-to> --hard

That’s it. Now your new branch will contain the commits you made on develop and develop will be back where you want it.

The Development Experience

When writing Elm code I spent quite a lot of time trying to appease the compiler. I would make a change to the code and the compiler would tell me I did something wrong. I’d make another change and the compiler would become angry again.

It was a vicious cycle.

You may think this would slow your development down tremendously. Well… You’re right. It does, but the pay off is worth it. After I won my first major battle with the compiler and my app finally rendered in the browser, the first thing I did was open the dev tools and start clicking around. I did not believe the compiler when it told me everything was fine.

Coming from the JavaScript world, I was sure there was a runtime exception waiting to be thrown. I just needed to find it. But after a few minutes of adding and completing to do’s I could not break my app. The compiler was right.

With Elm you have a pretty strong guarantee that if your code compiles it will run without error. This guarantee is made possible by Elm’s type system and compiler working together to minimize the number of mistakes you make while building your application.

The Type System

The type system was one of the main reasons I was interested in Elm and other functional languages. The ability to describe and model your data in a more meaningful way was very appealing. It is like being able to communicate with your application on a deeper level by describing exactly what you want the shape of your data to be.

For instance, in my to do application I define a to do as such:

type alias Todo =
  { title : String
  , completed : Bool
  , id : Int
  }

Comparing that to JavaScript, all we would have to work with is an object with default values.

const todoModel = {
  title: '',
  completed: false,
  id: 0,
};

The type alias above does not seem particularly special at first, but the power becomes evident once you begin to leverage that definition throughout the application.

One example is how the Todo type is used inside the model’s type definition.

type alias Model =
  { newTodoTitle : String
  , todoList : List Todo
  , currentFilter : Filter
  , prevId : Int
  }

As you can see above, I was able to tell the Elm program that the todoList was not only a list but that the list was to contain only Todo’s. Now Elm knows exactly what I want my list to contain.

Having never worked with a statically typed language before Elm’s syntax and features took a little getting used to. Fortunately the Elm community and Evan Czaplicki, the creator of Elm, are focused on making Elm easy to use. This means that while there is a slight learning curve to Elm it is not as drastic as other languages.

One of the biggest benefits of Elm’s type system is it encourages you to spend time up front determining the structure of your application. As developer’s, we tend to want to get our hands on the keyboard and start building something as quickly as possible, which can cause us to neglect forethought and planning. It is nice to have something to remind you that those things are necessary.

The Elm Architecture

Elm web applications have a preferred structure known as the Elm Architecture. It consists of a series of functions (model, view, and update) that describe your app and the way it can change.

A very brief explanation of the Elm Architecture is the model holds the data/state of your application, the view function describes to the Elm virtual DOM what to render, and the update function receives messages from the view and returns a new model describing the updated state of your application.

Having used Redux before and knowing it was inspired by the Elm Architecture, I had a basic understanding of what was going on. Unlike with Redux, you do not have to wire together the Elm Architecture. The language takes care of that for you. Honestly, this bothered me a little when starting on my app. I wanted to understand what was going on behind the scenes. Once I accepted that Elm would take care of connecting things, working with the Elm Architecture was very pleasant.

The Tooling

I want to start by saying the tooling around Elm is pretty great. The packages for the Atom editor add a lot of cool features for working with Elm. I really enjoyed the inline compiler errors provided by the Elm Linter, the autocompletion provided by Elmjutsu, but by far my favorite was Elm Format.

Coming from a JavaScript background the formatting of Elm was a little strange at first. The ability to just throw some Elm code on the page hit cmd-s and have Elm Format take care of the formatting was great. It allowed me to maintain focus on trying to solve the current problem instead of getting caught up with formatting.

I also found Elm Reactor to be an invaluable tool while working with Elm. To have your code compiled on the fly and see your changes reflected in the browser made developing with Elm almost as easy as modern JS development.

I am already itching to do another rewrite, though. This time with Elm =) I guess that is the developer’s eternal struggle.

Vue

Overall working with Vue was very pleasant. The .vue files are a very cool way to organize your code on a component level. You can combine all the HTML, CSS, and JavaScript that make up your component into a single file. This allows you to seamlessly create reusable components.

Like many of the modern frontend frameworks and libraries Vue has the vue-cli which makes setting up your build and dev environments trivially easy. It does the heavy lifting of setting up the Webpack configs including hot reloading and production build file.

My Journal

I wanted a way to write a “blog” without having to store the entries on a server. Of course, I could have used a static site generator like Jekyll, but I wanted to try out Vue.

The solution I came up with was to write the entries in markdown and use Node to compile the markdown to HTML using Showdown.js. Once I have the HTML, I generate a JSON object made up of the markdown and some metadata about the post. I then import the JSON file into my Vue app so it is available to display.

To add syntax highlighting for the code in the journal entries I used Highlight.js. When a JournalEntry component loads it finds all the code elements and uses highlightjs to add syntax highlighting.

Building the Journal this way gave me some of the same benefits of using a static site generator like the posts being version controlled and not needing a server or database, but it also allowed me to give Vue a try. It also allowed me to get some practice in with manipulating files and directories using Node.