From Jeremy Keith:

Your app should work in a read-only mode without JavaScript. Without JavaScript I should still be able to read my email in Gmail, even if you don’t let me compose, reply, or organise my messages.

I like this take on progressive enhancement. JavaScript is the language for interactivity on the web. Reading does not require two-way communication.

Today I was looking for a way to create a custom Laravel validation rule without the overhead of a new class. The rule I needed would only be used in one place, so wanted to keep it close to (or in) the request class.

Upon re-reading the validation docs, I learned that Laravel supports closures as rules.

class JournalEntryRequest extends Request
{
    public function rules(): array
    {
        return [
            // …
            'lines' => [
                function (string $attribute, mixed $value, Closure $fail) {
                    $debit = collect($value)->where('type', 'debit')->sum('amount');
                    $credit = collect($value)->where('type', 'credit')->sum('amount');

                    if ($debit !== $credit) {
                        $fail("Debit and credit don't match.");
                    }

                    if ($debit !== 0) {
                        $fail("Amount must be greater than 0.");
                    }
                },
            ]
        ];
    }
}

Just what I needed!

Caleb Porzio released this podcast episode earlier this year, but it’s been simmering in my head ever since.

The gist is to take things as far as you can before asking others. Instead of opening an issue, open a PR. Instead of replying “I don’t know”, find out. Before asking a question, write down the problem to make sure you’ve considered evey angle yourself.

Dealing with interactions this way gets things done more effectively, gives you the opportunity to learn something, and turns you into a nice person.

Last week, we launched a redesigned for Flare, our Laravel error tracker.

I contributed to the app UI, but most of the work was done by Digital With You, who provided us with the design, and the team that implemented it: Alex, Freek, Rias, Ruben, and Sam.

Check it out for yourself! Or read our launch post for all the nitty gritty details.

Standards are useful, but after a while they represent the beliefs of the past, not the needs of the future.

A good quote from Mathias Verraes on standards.

Thanks to my colleague Sam I recently learned about the form attribute on the <button> element.

By setting a form attribute, the button becomes a submit button for a form on the page with that ID, without having to nest the button on the page.

This could be useful for a logout link, used on different places.

<nav>
  <!-- … -->
  <button type="submit" form="logout">
    Log out
  </button>
</nav>

<footer>
  <!-- … -->
  <button type="submit" form="logout">
    Log out
  </button>
</footer>

<form id="logout" method="POST" action="/logout">
</form>

If you’re going to read one thing today, make it this. So much good stuff in here I could quote just any paragraph.

complexity is spirit demon that enter codebase through well-meaning but ultimately very clubbable non grug-brain developers and project managers who not fear complexity spirit demon or even know about sometime […]

grug no able see complexity demon, but grug sense presence in code base

Rich Harris & the rest of the Svelte team have previously mentioned that they use TypeScript with JSDoc instead of .ts files. That gives TypeScript’s safety benefits during development and on CI, without an additional build step.

There are a few nuances to this, Pascal Schilp did a great job reviewing the background and benefits behind this decision.

When you define too much work up front, you add unnecessary management overhead. More importantly, you create a bias and stifle a team’s creativity to solve the problem.

No one defines all the work up front. That’s a fools errand. Assuming you know too much up front is the best way to find out you’re wrong in the end. Instead we define the direction, the purpose, the reason, and a few specific “must haves” up front. The rest — all the rest, which is mostly everything — is determined during the project, by the people on the project.

When you want to compare two database columns in Laravel, you can’t use where because it treats the argument you’re comparing to as a value.

Instead, Laravel has a whereColumn method you can use to compare a value to another column’s value.

// Retrieve posts that were updated after
// they were published.

Post::query()
    ->whereColumn('updated_at', '>', 'published_at')
    ->get();

Timeless advice from Freek & Brent.

Just like reading text, grouping code in paragraphs can be helpful to improve its readability. We like to say we add some “breathing space” to our code.

$page = $this->pages()->where('slug', $url)->first();
if (! $page) {
    throw new Exception();
}

$page = $this->pages()->where('slug', $url)->first();

if (! $page) {
    throw new Exception();
}

Just one line of space can make the difference.

As I’m refactoring an existing design system, this article by Elise Hein came quit timely.

We consider HTML to be cheap, but wrapping divs in divs in divs comes with a cost that slowly creeps up.

Why avoid extra wrapper elements?

1. Bloated html hurts performance
2. Redundant elements can create problems with accessibility
3. Redundant elements can break styling
4. Deeply nested dom trees are annoying to work with

When using whereHas in Laravel, it’s not uncommon to also eager load the relation using with.

$posts = Post::query()
    ->with('author')
    ->whereHas('author', function (Builder $query) {
        $query->where('name', 'Seb');
    })
    ->get();

Laravel also has a more succinct method that combines the two: withWhereHas.

$posts = Post::query()
    ->withWhereHas('author', function (Builder $query) {
        $query->where('name', 'Seb');
    })
    ->get();

Since this blog is a static site, I don’t have a server running to do something dynamic when I publish a new post. I was about to set up Zapier or IFTTT to auto-toot blog posts to Mastodon, until I realized I finally had a use case to give val.town a shot.

With val town you can write lambda-ish functions in a GitHub gist-ish interface. Single functions are called “vals”. The fun part is you can reference your own and other people’s vals, which creates a network of atomic actions you can stack like Lego blocks. Vals can be scheduled so you can use them as background services.

First I created a generic postToMastodon val to toot a status on Mastodon. Then I created a tootLatestPosts val that combines it with an existing @stevekrouse.newRssItems val, which fetches RSS items from a feed.

Finally, I scheduled tootLatestPosts to run every hour. Now posts from this blog automatically appear on my Mastodon profile!

I was building wireframes for a website with HTML & CSS. Since it’s a prototype, not all actions are functional. When a visitor reviewing the prototype tries to click something that isn’t hooked up, I wanted to clarify what they could interact with. This also allows visitors to click anywhere on the page to highlight what they can click.

In the past, I’ve used JavaScript to add an outline to clickable elements when something non-interactive was clicked. But with the :has and :is selectors, this is doable with plain CSS.

html:active:not(:has(a:active, button:active, label:active)) :is(a, button, label) {
  outline: 2px solid blue;
}

How it works:

• html:active will match whenever you hold down your mouse on the page
• :not(:has(a:active, button:active, label:active)) will not match when you’re holding down your mouse on an a, button, or label element, to avoid the outline from appearing when the user clicks something that is functional
• :is(a, button, label) matches all a, button, and label elements on the page

View a demo on CodePen.