DEV Community: Bryan Lee

Migrating Hugo to Eleventy - Initial thoughts

Bryan Lee — Sat, 29 Feb 2020 18:34:24 +0000

I've just spent one afternoon and a couple of hours after dinner migrating this blog from Hugo to Eleventy and also refreshing the design a little. The paint has not even dried yet but I am really amazed and delighted about how enjoyable and easy the migration was.

Why Eleventy?

Hugo has been perfectly fine for my blog, but as my projects at work are going towards more JAMStack, I thought I'd update myself about the latest developments in this area. Eleventy caught my attention primarily due to it being written in JavaScript which is something I am extremely at home with.

The other very interesting point about Eleventy is that it aims to be as agnostic as possible. It does not take a stance between React or Vue, and you can freely choose to write your layouts in Liquid, Nunjucks, Pug, or just plain HTML. You can also have different layouts written in different languages.

Smooth setup and migration process

The whole process from installing Eleventy to publishing it live on Netlify took me 5-6 hours, not bad considering that I also rewrote the HTML and CSS again from scratch. Disclaimer alert - my blog is a simple website.

Migrating my blog post markdown files over was fairly easy. I had to tweak the front matter a little to make them compatible with Eleventy. I was using tags in Hugo for grouping my posts, but tags are used by Eleventy Collections in a slightly different manner and didn't really transfer over. I had to rename a couple of other attributes too, but nothing too difficult for a few full-text search and replaces.

No Webpack

One thing you'll quickly notice is the glaring absence of Webpack. I needed to handle image assets and also to use SCSS. No biggie too, there is already a SASS plugin for Eleventy. Eleventy does not support SVG files by default but there is also a community plugin to cover this. No Webpack was involved at all and I found this really refreshing without having to fiddle with Webpack config files and getting my hands all greasy.

Intuitive templating system and awesome documentation

I rewrote the HTML and CSS from scratch with some tweaks to the design and found the Eleventy documentation to be really well-written. I loved how you can just chain layouts together to create different variations. The directory structure is also really simple. All layouts go into the _includes folder, and you specify in your front matter which layout you want.

# Specifying layouts
layout: layout.liquid # Loads layout from _includes/layout.liquid

Eleventy also has this concept of Data Cascading to merge data from various sources. You can use this to specify that you want all your blog posts to load a different template from your sitewide default, and you can also even load a post-specific template. I like this declarative approach much more than directory-based inheritance approach which Hugo used.

// posts/posts.json - Data here affects all your posts content
{
  "layout": "blog-post.liquid" // All your posts will use the layout from _includes/blog-post.liquid
}

# posts/special-post.md
layout: special-occasion-layout.liquid # Only this post will use a different layout from the rest of your posts

Unopinionated and flexible

Eleventy comes with support for a range of templating languages out of the box (Liquid, Nunjucks, HAML etc). As I wrote in the beginning of this post, you can also use different languages for different layouts. I loved not being forced into a templating language that I'm not familiar with or one that I'm not a fan of. I decided to go with Liquid (yay Shopify) which itself is also really pleasant to work with.

I also see how Eleventy is just plain Javascript and not built on top of React, Vue or any other framework a huge plus. Given how fast things move in the frontend world, you could wake up tomorrow and X framework is no longer cool. Plain old JavaScript will always be here, and I can always write my own Eleventy plugins without having to keep up with a framework I may not be familiar with.

What about the bad?

I've been singing praises for Eleventy this entire post. Does this mean Eleventy is the best static site generator there? I definitely don't think so. I've still not spent a lot of time with Eleventy yet. My experience so far has been these couple of hours migrating from Hugo although it has been a very pleasant one indeed. My blog is also a very simple website which also means I am not pushing Eleventy to its limits yet. As I play around more, the parts where Eleventy do not do well will start to be more visible and I hope to do another post on this then.

This post was first written on my blog where you can find more posts related to frontend development.

Creating a Share Extension in NativeScript

Bryan Lee — Thu, 03 Oct 2019 13:56:09 +0000

Share extensions are a type of app extension in iOS that extend functionality to your app. Users will be able to share other forms of content with your app. Think sharing an article you enjoy in Safari over WhatsApp, your photos over Instagram. Nativescript as of version 5.3 has also introduced beta support for share extensions. I have worked with NativeScript to launch a share extension enabled app into production and found the overall process pleasant.

A primer to share extensions

Before diving into creating a share extension, let's understand how share extensions work. Share extensions are bundled together with your main app but have their own life cycle and environment. Unlike your host app, the share extension is not run until the user chooses it from the iOS share sheet. One other thing to note is that the share extension does not communicate or share data directly with the host app. In iOS, related apps and extensions share data via App Groups.

Creating a share extension in NativeScript

Creating a share extension in NativeScript is largely similar to how you would do it natively via Xcode. If you already have experience with doing it natively, feel free to skip straight to the NativeScript-specific part. Otherwise, the process looks like this:

Using Xcode to scaffold a share extension
Integrating it into NativeScript's build process
Coding your share extension
Sharing data with your host app

Scaffolding a share extension with Xcode

First, we will want to use Xcode to generate a scaffold of our share extension. This will give us a basic working share extension. Open your NativeScript app's iOS Xcode project located in platforms/ios. NativeScript uses CocoaPods, so make sure you open the .xcworkspace file instead of your .xcodeproj file.

There are already countless guides out in the wild documenting how to do this in Xcode, so I will link you to the official Apple one instead of repeating it here. Feel free to go with either Swift or Objective-C as both will work with NativeScript.

After this, you will need to setup an App Group to share data between your extension and host app. In Xcode, go to your project's capabilities tab to create a new App Group. In your list of project targets, go to your main host app and enable the App Group for it as well.

Integrating your share extension into your NativeScript app

You have a working share extension in your Xcode project already, but it is not yet integrated into NativeScript. However, as this is created inside Xcode, NativeScript will override them the next time you run tns prepare.

In Xcode, you will see a newly generated folder for your share extension. Replicate the contents inside to app/App_Resources/iOS/extensions/your_share_extension_folder. Now when you run tns prepare, it is copied into your Xcode project.

When you build and run your app in Simulator now, you should see a new share extension for your app when you open up the share sheet in Safari. Congratulations!

Retrieving share extension data in your NativeScript app

This guide will not go into the specifics of coding out the share extension as well. Instead, let's explore how we can retrieve data shared from your extension. To recap what we have done previously, we created an App Group, which will let us share data between the extension and host app.

In your extension, you will probably be saving data into the App Group via UserDefaults:

self.userDefaults = [[NSUserDefaults alloc] initWithSuiteName:GROUP_IDENTIFIER];
[self.userDefaults setObject:shareJsonString forKey:@"share"];

In NativeScript, the Application Settings module is used to interact with iOS's NSUserDefaults. However, Application Settings is limited to only interacting with the app's User Defaults. To do so with our App Group, we will have to use the native APIs.

import { isIOS } from 'tns-core-modules/platform';

const userDefaults = isIOS ? NSUserDefaults.alloc().initWithSuiteName('group.com.yourapp.shareext') : undefined;

# Retrieving the value from a key
userDefaults.valueForKey(key)

Debugging your share extension

When using Nativescript CLI to build and run your app, you will see that the console only outputs logs from your host app. Should you need more in-depth logging or utilise other debugging strategies like breakpoints, you will need to target the share extension in Xcode and run it. Share extension related logs will be output in the Xcode console.

Overall, the process of developing a share extension in NativeScript went quite smoothly for me. Though support by NativeScript is only in beta, it is good enough to be deployed into the wild as a production app. Creating a share extension is a complex topic by itself and even more so doing it in NativeScript. I am sure I have overlooked some details in writing this guide. Please feel free to reach out if there is something else I can clarify more on or if you have any questions / feedback.

This post was first written on my personal blog where you can find more posts related to NativeScript development. Feel free to also reach out to me directly over LinkedIn or Twitter.

Vue Renderless Component Fun: Google Analytics Event Tracker

Bryan Lee — Sun, 30 Jun 2019 09:29:45 +0000

Let's say you needed to track how many times a specific button in your Vue app is clicked on using Google Analytics, how would you do it? The first thing that comes to mind might be with a click handler.

<button @click="onClick">Important Button</button>

methods: {
  onClick(e) {
    ga('send', 'event', 'Video', 'play')
    // Other things the button does when clicked
  }
}

This is a perfectly fine approach, but as you start tracking more button and link clicks, this can get cumbersome. With renderless components in Vue, we can abstract the event tracking into its own easy-to-reuse component.

What is a Renderless Component

A normal Vue component has a HTML template, Javascript and CSS. A renderless component does not have its own markup. It usually has a render function that renders a scoped slot. Data and function from the renderless component gets passed to the child component through the scoped slot. This simple concept essentially lets you to abstract out complex behaviors that can be reused with different components.

To illustrate this better, we will build a renderless component that you can wrap around buttons, links and other elements to track clicks in Google Analytics. Let's start off by scaffolding a renderless component we shall call Track.

// Renderless component
// Track.js
export default {
  render() {
    return $this.$slots.default;
  }
}

// App.vue
<template>
  <div>
    <track>
      <button @click="onClick">Important Button</button>
    </track>
  </div>
</template>

<script>
import Track from 'track';

export default {
  components: { Track },
  methods: {
    onClick(e) {
      // the button's own click handler function
    }
  }
}
</script>

We import our new Track component into our App component, and wrap it around the <button> element which we intend to track. Track here is a very basic renderless component. All it does is render a default slot, in this case, rendering the <button> which we've wrapped around with. If you refresh your page now, you would not notice any difference. The Track component is transparently rendering the child button, it has no markup of its own.

Listening to Clicks

Now, we want to start making our Track component useful. We want it to listen for clicks on its child element and then send call the Google Analytics API when there is one.

// Track.js
export default {
  render() {
    return $this.$slots.default;
  },
+ mounted() {
+   this.$slots.default[0].elm.addEventListener('click', this.trackClick, true);
+ },
+  methods: {
+    trackClick() {
+      ga('send', 'event', 'Video', 'play');
+    }
+  }
}

Let's go through what we just did. We are declaring in our component's mounted lifecycle hook after it is rendered that we are adding an event listener. this.$slots.default means that we are accessing the component's default slot. We are looking for only the first element, and we add an event listener for click events. If there is a click, we run the trackClick function.

The last argument in addEventListener is true says we want to use event capturing instead of the default event bubbling. Event capture means that events are dispatched top down the DOM tree to our listener instead of the default bubbling up the DOM tree. In actual effect, this lets us also listen to clicks even if there is a preventDefault declared.

Making it More Reusable

There is one slight issue left. What if we want to track another link in another page? Looking at our code again, all clicks will be calling this ga('send', 'event', 'Video', 'play'). Let's make it so that we can customise the different variables we want to send over to Google Analytics (GA) using props. We shall also follow the standard fields set by the GA API.

// Track.js
export default {
  render() {
    return $this.$slots.default;
  },
+ props: [
+   eventCategory,
+   eventAction,
+   eventLabel,
+   eventValue,
+ ],
  mounted() {
    this.$slots.default[0].elm.addEventListener('click', this.trackClick, true);
  },
  methods: {
    trackClick() {
-     ga('send', 'event', 'Video', 'play');
+     ga('send', 'event', eventCategory, eventAction, eventLabel, eventValue);
    }
  }
}

Now, we can use it in different places with the relevant event fields:

<Track eventCategory="Checkout" eventAction="Button Click" eventLabel="Sidebar" eventValue="$30">
  <button>Some button</button>
</Track>

Happy Tracking!

Our Track component is now ready to use in other parts of the code. One advantage of abstracting out external APIs you gain is that code becomes more maintainable now. Google made an update to the GA API that requires an update? Instead of updating the 30 different places where the API call is used, you just update it in Track.

Another huge plus, your code base is more inclusive. Previously, a new developer that joins your team will also need some familiarity with the GA API on top of their Vue skills. Abstracting this into an intuitive concept that most Vue developers are already familiar with equals to more productivity from day one.

This post first appeared on Bryan Lee.