When I started working on this site, I was a little worried about how to break up the Blade and Vue templates. I love Vue and feel most comfortable building views with Vue, but the pages on this site don’t need AJAX calls and SPA-like functionality. I could totally go down that route, but it seemed simple and more user-friendly to just generate the views server-side with Blade templates and pass along props to any Vue components I might have as per Caleb Porzio’s suggestion.

I still wanted to try my hand at making AJAXy forms so I could use Sweet Alert to do fancy message pop-ups. Probably unnecessary, but I wanted to try it. I then worried about people needing JavaScript just to do a simple form. So, in the event that JavaScript isn’t available, I want the form to just be a regular form, but if JavaScript is available (as it usually will be), it used the Vue component. Luckily, whatever you stick in a Vue component’s slot will render when no JavaScript can be used. My solution was to wrap my forms with a renderless Vue component that spits up needed functions and data through a scoped slot. Here’s that component.

Definitely not perfect, but it’s an interesting use case for scoped slots and renderless components.

Dump that JavaScript

Published 2 months ago

By dumping, I’m referring to dumper.js. It’s a dd() clone from Laravel-land. The output is colorful and the data comes out looking like PHP var_dumps.

It’s a great alternative to console.log and PHP devs will feel like they never left Psysh.

Last month, I gave a talk at Vue.js Night in Nagoya about async components in Vue.js. I really got into the idea of code-splitting everything and loading as much as possible asynchronously. If you're interested in the slides (which were built as an async Vue app) check them out here.

Introducing laravel-mix-rails

Published 2 months ago

Continuing on from my previous post, I whipped up a little npm package to facilitate using Laravel Mix with Rails

You can see the package here.

Use it by running npx laravel-mix-rails.

Mixing Laravel and Rails

Published 2 months ago

This information is pretty much just a regurgitation of a Japanese post I found here. I didn't find anything on the topic of using Laravel Mix with Rails in English, so I thought I'd write this technique up myself. I love Laravel and its asset system Mix. The combo of Rails and Webpacker kind of sucks. I used to think Rails was amazing, but then I found Laravel and I saw how forward thinking the Laravel community is in regards to the frontend. They embrace the frontend and its trends, while the Rails community seems to fight against it whenever it can. So let's find a way to use the frontend and all its wonderful abilities while still having access to Ruby on the backend.

Inside laravel_mix_helper.rb, drop this inside:

module LaravelMixHelper
  class LaravelMixError < StandardError; end
  MANIFEST_FILE = 'public/mix-manifest.json'
  def mix(path)
    unless File.exists?(MANIFEST_FILE)
      raise LaravelMixError.new('The Mix manifest does not exist. Run `npm run dev`.')
    end
    manifest = JSON.parse(File.read(MANIFEST_FILE))
    asset_path(manifest[path])
  end
end

Inside webpack.mix.js, include this:

let mix = require('laravel-mix');
mix.setPublicPath('public')
  .js('resources/js/app.js', 'public/js')
  .postCss('resources/css/app.css', 'public/css')
// Cache-busting
if (mix.inProduction()) {
  mix.version()
}

Then, in your app/views/application.html.erb, reference your new asset files like this.

<link rel="stylesheet" href="<%= mix('/css/app.css') %>">
<script src="<%= mix('/js/app.js') %>"></script>

Now you can run npm run watch to get your dev server going, and run npm run production when you're ready to push. Relatively easy to set up, and way better than Webpacker.

Hunger and Guides

Published 2 months ago

There's a lot to be said for turning the tasks in your productivity system into guides. Instead of checking OmniFocus to see if you need to wash the dishes or do the laundry, you're better served by taking notice of the dishes or clothes that are piling up and then acting on that guide. After considering the role of guides vs. tasks, I've found there's been a great weight lifted off of me in regards to task management. I used to have silly tasks popping up in my OmniFocus Dashboard every day. Things like "wash dishes", "do laundry", "brush teeth" and "take out the trash". I then made them Considered Tasks for a while, with names like "Consider taking out the trash". This was just as bad. Some things are best left to guides. Go through your task manager and see what mundane tasks can be left to guides. In OmniFocus, you can assign these tasks to a "Retired Habits" context that's placed "On Hold". Try living without these tasks for a few weeks and see if you're functioning just as well without seeing them pop up flagged and screaming for your attention. If the guides are working, delete the tasks. If they aren't maybe you need to work on building the habit a little more.

The best way I've found to improve the effectiveness of guides is to make the guides more visibile. An inbox or laundry basket with a lid is harder to see than an inbox or laundry basket without a lid. Lidded baskets allow us to shove things in, close the lid and not see what's really there. It's why we buy cabinets for books, videos and games that we don't want to see---because we know that deep down we don't really need all these things. Also, make the baskets smaller. A small laundry basket with no lid on it is going to fill up much faster than a bigger one, and with no lid to keep keep the mountain of dirty clothes at bay, the erupting volcano of laundry will get your attention in a much less nagging way than a due or flagged task in a task manager.

So, let's bring this idea of guides to health. Our ancestors didn't worry about eating breakfast, lunch and dinner. They found food when they could and they ate when they wanted. It's our manmade workday that's forced us into meals. Meals are like tasks. They are scheduled events that we think we have to get done. We should be thinking about hunger and meals the same way we think about guides and tasks. If we relied on our hunger to be our guide, we'd eat when we are hungry---instead of when we think we should eat. This idea is central to the Primal Blueprint. So while you're trying to use your guides for handling household chores, try listening to your body about when it's time to eat.