Vue 2 used to support callback refs, but removed in 2.2 because it caused bugs that were hard to fix without breaking backwards compatibility.

Callback refs are more powerful in comparison with string refs, with a very cheap price to pay: slight verbosity. Here’s an example of callback ref in action:

However, I won’t be going into detail here. Instead, we’ll discuss how to accomplish something given that callback refs are out of our choices.

Use case

Callback refs are particularly useful if you’re building a library, and would like to get a reference to a certain element from your slots.

…

If it looks stupid but works, it ain’t stupid.

If you haven’t read about render props before, check out:

Problem

You have a lot of sorting presets (Chronological, reverse-chronological, alphabetical, et al).

For performance reasons, you want to store the filtered array into your state instead of doing the filtering inside the render. However, your component already does so much, you want to separate this functionality.

What if we could ensapulate this into a separate component that does all of this for us? Render props to the rescue!

Idea

What if we could do this?

SortingLayer satisfies our requirements. In…

If you’re fairly new to building UIs, specifically with React, deciding the data structure for the states of each item in a collection can be quite tricky. But as you progress and learn techniques, especially this one, hopefully this kind of task becomes less terrifying.

Scenario

Here’s an example of the UI we need to build.

States

• Uploading
• Progress
• Failed
• Complete (default)

Initializing the state

To do the UI above, this data shape is key:

class Uploader extends React.Component {
  state = {
    uploading: {},
    progress: {},
    failed: {}
  }
}

That’s it.

Whoa, objects?!

Yes, instead of an array. This makes it easier to access state…

Oftentimes, there’s unwarranted extra effort in building a reusable component that can be either async or sync based on the provided props.

There’s extra if-else statements around the place; it makes a lot of noise. This just makes it harder to read, all the more so change. At least, for me.

How do we build this? What if we could build these components differently? What if we could compose them instead?

Scenario

This case is common in CRUD features. Let’s take GitHub’s issue submission page as an example; the assign member widget specifically.

Sync

When using Eloquent’s scoped queries, use the $query provided as the first argument.

Wrong

class Post extends Eloquent {
 scopeRecent() {
   $weekago = //;
   return $this->where(‘created_at’, ‘>=’, $weekago);
 }
}

This will work but not produce correct results.

Correct

class Post extends Eloquent {
 scopeRecent($query) {
   $weekago = //;
   return $query->where(‘created_at’, ‘>=’, $weekago);
 }
}

I rarely use the docs since I’ve been using Laravel for years now. But this — this has bitten me a number of times.

Inevitably, the typical (but reckless) setup in the becoming-common API-centric development is having the backend and frontend work at the same time.

However, because the frontend relies on the backend, slight delays from the backend can cause detrimental impact to the team’s productivity and deadlines.

Use case

Like most methodologies, apply this where it fits. I think common applications that are mostly made up of CRUD features can benefit from this method.

Moreover, I think this is a good way to start a new project.

The “Solution”

But what if instead of trying to making a compromise the timeline between the frontend and backend…

Currently, Envoyer does not yet have any option to skip composer install. This was initially a downer because I’m deploying a Laravel application running on Docker.

But it was actually quite a simple feat to accomplish through Deployment Hooks.

How-To

In the Install Composer Dependencies action, add a pre-hook that moves composer.json outside the release folder:

cd {{release}}
mv composer.json /tmp

And a post-hook that moves composer.json back to the release folder:

cd {{release}}
mv /tmp/composer.json ./

Deploy your application afterwards.

Explanation

Basically, Envoyer runs the composer installation in the mentioned action (as the name dictates) if composer.json is found in the release directory.

Using a simple programming concept to help you test React components.

The Problem

It’s annoying when your cli / your browser console is filled with utter crap due to proptype issues. This usually arises when your component has bazillion proptypes.

This is how your console (browser console/cli) may look like in testing components that have multiple reponsibilities (at least mine when I run karma (a test runner)). It’s annoying because it doesn’t give you a clear context where things went wrong.

What we want is a clear-white console, just like this: