Custom Block Helpers and Meteor Composability

Written by Pete Corey on Jan 13, 2015.

I’ll admit it; working with AngularJS has left me with a certain sense of entitlement. I expect my front-end framework to be able to let me build distinct elements that can be composed together and placed within each other. After reading about Meteor’s templating system, I was under the impression that content could not be transcluded into a template. After all, where would it go?

{{> myTemplate}}

It wasn’t until I read through Spacebar’s documentation that I found out about the amazingly useful custom block helpers. Custom block helpers let us inject or transclude content (HTML, text, variable interpolations, other templates) into a template. Let’s check it out!

Using Custom Block Helpers

If you read through the Custom Block Helpers section of the Spacebar docs, you’ll notice that Template.contentBlock behaves almost exactly like AngularJS’ ng-transclude directive. It marks the place where content will be injected into the template’s markup. Let’s look at an example:

<template name="myTemplate">
    {{#if this}}
    <h1>{{title}}</h1>
    <div>
        {{> Template.contentBlock}}
    </div>
    {{else}}
        <h1>No content provided</h1>
        <div>
            {{#if Template.elseBlock}}
                {{> Template.elseBlock}}
            {{else}}
                <p>No elseBlock provided</p>
            {{/if}}
        </div>
    {{/if}}
</template>

<body>
    {{#myTemplate title="My Title"}}
        <p>My custom content</p>
    {{else}}
        <p>This is my else block</p>
    {{/myTemplate}}
</body>

There’s a lot going on in this example. Let’s break it down.

Check Your Context

The first thing I do in my template is check the truthiness of the template’s data context (this). If a truthy data context is passed into the template, I render one set of markup (which includes data from the context), otherwise, I render an alternate set of markup.

Inject Your Content

You’ll notice that I’m using Template.contentBlock in the first set of output and Template.elseBlock in the next. Interestingly, when you define a custom block helper, you can also define an “else” block to go along with it. In the second set of output I’m checking if Template.elseBlock is truthy. If it is, I render it, otherwise, I render some markup explaining that an else block was not provided.

Use Your Template

To actually use your new template and inject content into it, you no longer use the inclusion tag syntax. Instead, you reference your template using block tag syntax. You can see this at the bottom of the above example. Within your block tag you include your content to be injected and an optional else block. Note that any arguments you pass into your template becomes that template’s data context.

Final Thoughts

While the above example is completely contrived and mostly useless, I think it shows some really useful functionality. I feel like custom blocks are going to be a big game changer in my Meteor development workflow. There’s a great article over at Discover Meteor that touches on custom blocks with a more practical example. Check it out!

Zapier Named Variables - Scheduling Posts Part 2

Written by Pete Corey on Jan 5, 2015.

Last time, I talked about using Zapier to schedule Jekyll blog posts with Github Pages. I briefly touched on how I wished that Zapier had some kind of string manipulation functionality to help pull a schedule date out of the git commit message. Not long after the post went live, @zapier sent me a link that helped me accomplish exactly that.

Named Variables

Named variables in Zapier allow you to break apart your trigger data into multiple fields accessible from within your zap. In our case, named variables allow us to specify our Scheduled field anywhere within our git commit message and then use it when creating our Google Calendar event.

Integrating named variables into the scheduler zap was incredibly simple. First, push a git commit with the Scheduled variable somewhere within the commit message:

Scheduling this post for Monday, the 5th at 9 in the morning.

Scheduled(1/5/2015 9:00AM)

After the commit has been pushed to Github, I edited the scheduler zap and in step 5, changed the Start and End Date & Time fields from using Commit Message to using Commit Message Scheduled.

That’s it! Now, my git commit messages can contain useful information as well as scheduled dates which can easily be parsed out and used by Zapier.

I’ve shared an updated template of this zap. You can grab it here.

Scheduling Posts with Jekyll, Github Pages & Zapier

Written by Pete Corey on Dec 29, 2014.

I’ve written a few times about using Jekyll and Github Pages as my blogging stack. So far, I’ve been very satisfied with this setup except for one pain point. I’m unable to easily write posts and schedule them to go live at a later date… Until now! While I could have written and hosted a script or two to accomplish what I was after, I wanted to take a different approach. I ended up using Zapier to automate the publishing of posts at future dates.

The Game Plan

The basic idea behind using Zapier to schedule future Jekyll posts with Github Pages is two part. First, create a git branch that holds commits for posts you want scheduled for release. A zap listens for commits pushed to this branch and creates a Google Calendar event at the date and time you want to schedule the post to go live. A second zap listens for these calendar events to start and creates an instant-merging pull request into master from the post’s commit.

Scheduling Posts

The first zap will listen for commits to a specific branch (I called mine scheduled) on a Github repository.

When a commit is pushed, Zapier will create a Google Calendar event at the date and time specified in the git commit message. It will also store the SHA identifying the commit in the location attribute of the calendar event.

It’s important to note that scheduling posts in this way means that the only text you can put into your git commit message is the date and time the date will go live. Actual commit messages may give unexpected results.

I’ve shared a zap template for this step.

Merging to Master

The next step of the process happens when the Google Calendar event starts (when your post is scheduled to go live). A second zap is triggered when this event starts. The zap pulls the post’s SHA from the location attribute of the event and create a Github merge request into master. By making the merge an “instant merge”, the commit will immediately be pulled into master, which in turn causes Github to rebuild your Jekyll site.

I’ve shared a zap template for this step as well.

On Zapier & Final Thoughts

Sure, I could have implemented this as a shell script or simple program in a variety of ways, but I think that Zapier is a really elegant solution to this problem. The way Zapier composes webapps together is very interesting, vastly useful and can come with some unforeseen benefits. For example, using Google Calendar as the driver of my scheduling system has an added benefit of giving me a nice user interface to modify release dates of posts before they go live. I could also easily trigger things like tweets, emails, etc. to be send when a post goes live.

I did find myself wishing that Zapier came with a few string manipulation features. Instead of dumping the entire git commit into the calendar’s schedule date, I was hoping to slice out only a portion of the commit message, or use the last line or something. Maybe this kind of functionality will come in the future, or maybe it already exists and I just couldn’t find it. See my followup post on using named variables to extract a schedule date from the git commit message.

As a proof of concept, I’ll be scheduling this post to go live on December 29th, 2014. See you then!