DEV Community: Lukas Hermann

June 2021: Launching my first app

Lukas Hermann — Mon, 12 Jul 2021 15:38:17 +0000

Taking inspiration from Alex West I am starting to write monthly updates.

Launching a paid plan for stagetimer.io

Stagetimer was born on November 1, 2020, after I visited a friend's studio. He had to run back and forth to an old laptop to start and stop a simple timer app. I was sure someone made a simple cloud-synced timer app. You know, those .io/.so/.to mini-apps. But no, nobody made it. So I started to build that very evening.

I posted it on Reddit on November 19 for feedback and got (for my standards) a lot of positive responses. There were even some suggestions for paid features. So I continued building more features.

Finally, on June 13 I did what I never planned or even considered. I launched a paid plan for stagetimer.io. That very evening, to my utter amazement, I got my first subscriber. At the end of the month, I had six customers.

Lukas Hermann

@_lhermann

Got my 6th customer for stagetimer.io 😍

#buildinpublic

17:31 PM - 29 Jun 2021

For the first time in my life, I can post MMR (monthly recurring revenue) numbers. For the uninitiated, MMR is the holy grail for solo entrepreneurs. MMR is like a salary without the cons of being an employee. MMR means freedom, future, self-fulfillment, independence, flexibility, no more 9-to-5 grind, and no more advanced notice for vacations only to stay in the hotel the entire week due to rain. But it also comes with customer support, marketing, taxes, and the nagging feeling to always use your time productively.

Just to be clear, I have a full-time job with Laserhub. Stagetimer is my side project. But for me, it is also the beginning of a brighter future.

Stats

Stagetimer ↗ €52 MMR

Aller Anfang ist schwer.

– German Proverb "Every beginning is hard"

Schedule Script Execution in a Node.js Docker Image with Cron

Lukas Hermann — Fri, 23 Apr 2021 04:37:36 +0000

Cron is a popular tool to schedule tasks, it comes pre-installed on almost any Linux image such as Debian or Ubuntu. Cron can execute any command at a predefined time like 4:30 AM or every 2 minutes. For this reason, it is the first choice of developers for scheduled script execution.

A docker image is nothing else than a stripped-down Linux operating system and comes with cron. Most answers on StackOverflow suggest installing extra packages or building a custom image, but neither approach is necessary. The vanilla Node.js Docker image has everything needed to schedule the execution of javascript files.

Example with Code

I want to run a javascript file every 30 minutes inside my docker image. I want to use docker-compose¹ to start and stop the docker container.

Here's my docker compose file:

version: "3.1"

services:
  price-daemon:
    image: node:14-alpine
    working_dir: /home/node/app
    volumes:
      - ./:/home/node/app
    command: "/usr/sbin/crond -f -l 0 -c /home/node/app/crontab -L /var/log/cron.log"

I use the lightweight node:14-alpine² image and mount my current working directory as volume.

The command starts the cron daemon and it will look for the file /home/node/app/crontab/root. Remove -l 0 if you don't like a super verbose log. In my working directory I created the file crontab/root with this contents:

# min hour day month weekday command
* * * * * /bin/date --rfc-2822 >> /var/log/cron.log
*/30 * * * * node /home/node/app/scheduled.js >> /var/log/cron.log 2>&1

The second line is just a timestamp printed into the log file for debugging purposes. The third line executes the scheduled.js file and logs its output into /var/log/cron.log

And that's it. Pretty simple right?

Why the iPhone Timer App displays a Fake Time

Lukas Hermann — Mon, 28 Dec 2020 21:56:09 +0000

While building my event timer app called stagetimer.io I came across a peculiarity with displaying time found out that the iPhone timer addresses it by showing us a fake time. By definition, a countdown shows how much time is left. So if the countdown says 5s we assume there are 5 seconds left. But that's not the whole truth.

TL;DR

The iPhone countdown timer doesn't strictly display the correct time but adds 500ms, or half a second, to the remaining time. It does this to make the reading of time more intuitive for humans. The alarm at the end of the countdown is not affected by this 500ms inaccuracy.

Countdowns are tricky

Javascript likes to use milliseconds when dealing with time, 1000ms equals 1s. Here is an example of a 5s countdown that starts at 5000ms and uses the setInterval() function to deduct 10ms every 10ms, simple enough. Milliseconds are converted to seconds by dividing by 1000 and rounding down like so: Math.floor(milliseconds / 1000)

The timer jumps to 4s right when hitting start and once the timer switches to 0s there are still 1s to go. This makes a lot of sense when counting up, for example, 10:00 is displayed during the first minute of 10 AM, not 10:01, always rounding down. But for a countdown timer, this is counterintuitive. It is easier to understand if the timer has a fractional seconds display.

Now the timer displays 0.9s seconds instead of 0s to show clearly that there is still time left on the clock. However, I didn't want to show fractional seconds for my timer.

Checking how the iPhone does it

So now I was curious how my iPhone solves this conundrum. So I set my iPhone timer to 5s:

After I click "Start" the iPhone timer shows 5s, not 4s like in the example above. But it switches to 4s before a full second expired. It then counts proper seconds until it reaches 0s which, again, is not a full second. And if you tap "Pause" just after it jumped to 0s it will promptly jump back to 1s to show you that there is, in fact, still some time left on the countdown.

I figured that the good folks at Apple add an extra fake 500ms to the actual time to start that countdown display at 5s instead of 4s. The timer ends and the phone beeps if the actual time hits 0s and the "fake" time hits 500ms. So they faced the same problem I did and came up with a practical solution. After all, if you start a 5s countdown, it should start at 5s right? For illustration, here is my simple timer doing the same trick.

So there you have it, the iPhone timer is technically lying to you.

Edit: About rounding time

Some have pointed out that the problem could be solved more easily by rounding to the nearest second or rounding up instead of rounding down. This is correct. Suppose we have 5459543ms that we want to bring into the traditional form HH:mm:ss.

I first divided the number into hours, minutes, and seconds with the help of some modular arithmetic and applied the rounding afterward. Rounding down results in 01:30:59, which is correct, but rounding to the nearest integer or rounding up results in the impossible time 02:31:60.

time = 5459543
seconds = (time / 1000) % 60 // 1.517
minutes = (time / 60000) % 60 // 30.992
hours = (time / 3600000) % 24 // 59.543

However, rounding the time to seconds first 5460000ms, and breaking it down afterward yields the same result as described above with adding 500ms, namely 01:31:00.

time = 5460000
seconds = (time / 1000) % 60 // 0.000
minutes = (time / 60000) % 60 // 31.000
hours = (time / 3600000) % 24 // 1.517

Edit 2: In an earlier version I messed up my rounding as described. Many helpful, as well as helpful and insulting, comments pointed out my error. So in addition to learning about counting time I also learned how it feels to be wrong on the internet 😅

References:

The code from the animations in this article

Lessons learned from over 10 years of writing CSS

Lukas Hermann — Mon, 12 Oct 2020 07:16:49 +0000

Introduction

Through my years of using CSS, I have found some principles to stand the proof of time while others did cause me many headaches in the long run. I want to share with you the those that stood the test of time. If you have some good advice that is absent from this list please let me know, I am as much willing to learn as to share.

CSS is curious in that it is very easy to learn but near impossible to master.

Note: The advice in this article is concerned with the developer experience of CSS, and not with design, performance, or accessibility (though these are important). The following points will especially be of value to you if you need to maintain and extend your CSS codebase over longer periods.

Keep specificity low
#id selectors are evil
Treat !important like raw eggs
Avoid chaining (or nesting) of selectors
Don't combine element and class selectors
Organize your code by increasing specificity
Use few properties per class
Don't worry about sorting your properties
Follow a naming convention like BEM
Avoid using shorthands if possible
Keep presentation (CSS), semantics (HTML) and behavior (JS) separate

1. Keep specificity low

It is really important to understand CSS specificity first, here is an excellent article. In essence, whenever you want to overwrite styles applied by one selector, you need to exceed or at least match its specificity.

🚫 Bad: specificity of first selector is too high

#main .nav li {
  color: white;
}

.nav li.is-active {
  color: red; /* dominated by #main */
}

✅ Good: using as few selectors as possible

.nav-item {
  color: white;
}

.nav-item.is-active {
  color: red;
}

To avoid the specificity wars, you want to avoid adding selectors that are not necessary. Instead of .nav ul li use only .nav li or better just .nav-item. Points 2. - 6. of this article are hands-on practices to help you to keep your specificity low.

2. `#id` selectors are evil

Id selectors have the highest specificity. This means whenever you use one, you are forced to use it again every time you want to modify the element's style. This might work well when you write your code in the first place but causes a headache whenever you want to extend it. I recommend generally avoiding #id selectors in your stylesheet.

🚫 Bad: forced to use the #footer selector repeatedly

#footer .box {
  background-color: #333;
}

#footer .box:hover {
  background-color: #444;
}

✅ Good: avoid using #id selectors in you stylesheet

.box {
  background-color: #333;
}

.box:hover {
  background-color: #444;
}

Further Reading: This article of Harry Roberts shows how you can use ids without increasing specificity

3. Treat `!important` like raw eggs

!important is the ace of spades of CSS, it is the ultimate trump card, and it should be treated as such. If you use it to escape the frustration of dealing with specificity which has gotten out of hand, then you are using it wrong. Use it sparingly, with selectors that have a very narrow scope and where you are certain that you want it to overpower all other styles.

🚫 Bad: using !important to deal with specificity frustration

#header .nav ul li a {
  border-bottom: 2px solid transparent;
}

.nav a:hover {
  border-bottom-color: black !important;
}

✅ Good: calculated use with narrow scope

.text-center {
  text-align: center !important;
}

Note: If you want to customize a CSS framework like Bootstrap that sometimes uses selectors with high specificity you may not have a choice

4. Avoid chaining (or nesting) of selectors

Especially with pre-processors like Sass, it is very easy to nest selectors which, when compiled to actual CSS, will be chained like this: .a .b .c .d { ... }

This might seem attractive because it helps you to write very specific CSS, but it also leads to bloated CSS. Let's say you have a .list class which is used inside .header and also inside .footer.

🚫 Bad: selectors are unnecessarily chained

.list {
  list-style: none;
  margin: 0;
}

.list .list-item {
  display: inline-block;
}

.header .list .list-item {
  margin-right: 1em;
}

.footer .list .list-item {
  font-weight: bold;
}

✅ Good: using as few selectors as possible

.list {
  list-style: none;
  margin: 0;
}

.list-item {
  display: inline-block;
}

.list--spaced .list-item {
  margin-right: 1em;
}

.list--bold .list-item {
  font-weight: bold;
}

There are two problems with this:

To style the .list-item, the .list has to be carried along to match specificity.
After a while you may be afraid to touch .list .list-item for fear that you break the .list-item in .header or .footer and have to undo it. You will probably end up writing any changes in .header .list .list-item or .footer .list .list-item directly, thus bloating your CSS and making it harder to keep a good overview.

The solution is not to use chaining/nesting with .header and .footer but to add modifier classes which can be used in connection with the .list class instead. Now you can write an element like this inside your .footer:

<ul class="list list--bold">
  <li class="list-item">&copy; Lukas Hermann</li>
</ul>

Not only does this reduce specificity (why use .list .list-item if you can just use .list-item), it only introduces higher specificity where we want it: when using a modifier.

A note concerning this specific example: In the case of lists it is probably easier to use .list li (and .list--bold li respectively) to save yourself some classes in your HTML markup, but I wanted to make an example which is easy to understand.

Note: This principle lies at the heart of naming conventions like BEM which will be addressed more specifically below.

5. Don't combine element and class selectors

When you start writing CSS it seems intuitive to keep your classes very specific. We all have been burned by the cascading nature of CSS and it can be upsetting if you make a change in your CSS intended for one small part of your site only to discover that you messed up the design of five other places.

With this background, it makes sense to write selectors like div.card a.link because we want to make sure that only anchor tags with .link inside a div with .card will receive this styling. But doing this is like fighting windmills, but CSS features are not our enemy. As a rule, don't combine element and class selectors, ever! If you want to modify the styling of an element in a particular place, use a modifier class instead.

🚫 Bad: mixing element and class selectors

a.link {
  color: blue;
}

div.card a.link {
  color: green;
}

✅ Good: using a modifier class instead

.link {
  color: blue;
}

.link--green {
  color: green;
}

The advantages of modifier classes:

The purpose of the modification is easy to understand
It's easy to change or remove
It's easy to find all the places in your code where this modifier is used by doing a simple search for link--green in your whole project

Note: A probable exception to this role might be a .btn component. If you want to make sure that an anchor tag a.btn looks identical to a button tag button.btn because these two elements behave a little different in browsers. But even then you may just as well add all the necessary styling to .btn.

6. Organize your code by increasing specificity

If two selectors have the same specificity, the latter will be used. Therefore, to play to the strengths of the CSS specificity feature, it makes sense to organize your CSS file by increasing specificity. Put your resets and element selectors first, your normal classes afterward, and finish with your utility classes like .text-center or .nowrap where you can then safely use !important.

🚫 Bad: unordered styles makes it easy to miss overwrites

.text-center {
  text-align: center !important;
}

.btn {
  background-color: green;
}

a {
  color: blue;
}

.btn {
  /* overwrites green */
  background-color: red;
}

✅ Good: ordering your styles roughly by specificity

/* Elements */
a {
  color: blue;
}

/* Components */
.btn {
  background-color: green;
}

.box {
  border-radius: 3px;
  box-shadow: 0px 3px 8px black;
}

/* Utilities */
.text-center {
  text-align: center !important;
}

The advantages of ordering styles roughly by specificity:

You will always overwrite less important styles with more important ones
You have a rough guideline for where your things go inside your CSS file

Note: This principle was introduced as ITCSS by Harry Robers. It is a really useful CSS methodology to handle large-scale products. Here is the article introducing ITCSS. Harry even created a course on Skillshare just recently.

7. Use few properties per class

As a general rule, the more properties a class has, the less likely you are going to reuse it. Simply because of the fear that some of the many properties will not fit your other use case and you have to undo them, thus you might even end up writing another class with very similar properties.

A good way to know if your classes are too bloated:

Simply observing yourself how many resets (like margin: 0;) you are writing to undo other classes properties
If you feel uncomfortable about reusing classes or if feel bad about adding another property to a class, it's a sign this class is too bloated

Classes become bloated because many different concerns (aesthetics, spacing, typography) are packed together. A great way to improve this, even without dropping any properties, is to simply break it up into its different concerns.

🚫 Bad: bloated, properties of different concerns are mixed

.card {
  border-radius: 3px;
  box-shadow: 0 5px 10px black;
  padding: 2rem 1rem;
  font-size: 14px;
  line-height: 1.3;
  margin-bottom: 2rem;
}

Note: The bloated example is not overly bloated yet, but I think it brings the point across.

✅ Good: fewer properties keeps classes reusable

.card {
  border-radius: 3px,
  box-shadow: 0 5px 10px black;
  padding: 2rem 1rem;
}

.spacer {
  margin-bottom: 2rem;
}

.text-small {
  font-size: 14px;
  line-height: 1.3;
}

In the good example, the .card class only contains the properties which specifically define its aesthetics. The aspects of spacing and typography are outsourced into their own classes. Having broken up the class like this you can easily see how to reuse each of those classes and even extend them and add more classes like .spacer-large or .text-tiny which will be very useful.

Yes, this means that you have to add more classes in your HTML like so <div class="card spacer text-small">, and that's okay. It is much more comfortable, especially in the long run, to use such classes.

Some classes need a lot of properties, for example, a .button class has to unset many user agent (browser) styles for both, the <button> and the <a> tag. Therefore this rule should not be followed religiously for every case.

Tipp: Most CSS frameworks come equipped with a good set of reusable utility classes, watch out for them and use them!

8. Don't worry about sorting your properties

This one is a bit opinionated. Brad Frost did a survey on twitter how people order their CSS properties:

Brad Frost

@brad_frost

Having fun debating different clustering of CSS properties. How do you do it? Alphabetical? Clustered by type (box model, positioning, typography, etc)? Train wreck?

14:20 PM - 05 Feb 2019

13 140

Most people answered that they are grouping properties by some common traits like positioning, display, or color. Some may be OCD about it and sort it alphabetically. Personally, I have tried these different methods and haven't found any of them particularly useful in the long run. I basically always do scrambled egg ... or how Brad Frost put it, "train wreck".

If your classes have many properties some sorting rules usually become imperative to maintain an overview. But if you keep your classes slim, like suggested in point 7, it is really not necessary. Simply abide by some simple rules (like layout first, aesthetics last), and don't worry too much about the order otherwise.

9. Follow a naming convention like BEM

Some of the code examples in this article are using the BEM naming convention. I found it to be very helpful and recommend it wholeheartedly. It's easy to learn! Quickly head to this small introduction with good code examples of the BEM naming convention to get the idea.

Here are two points I struggled with at the beginning with BEM.

Don't nest elements

If you have a title within a header within a card, only "nest" maximum one level deep like so:

🚫 Nesting BEM selector produces ugly classes

.card {}
.card__header {}
.card__header__title {}

✅ Nesting BEM only one level deep is better

.card {}
.card__header {}
.card__title {}

It's best to use modifiers only on root elements

Modifiers on children can be used, but they make it hard to remember which child has which modifier. If possible, apply the modifier to the root element, this will keep your HTML markup and your CSS cleaner and therefore easier to see which modifiers are used or available.

🚫 Using BEM modifiers on children get's messy

.card__header--large { padding: 2em; }
.card__content--large { padding: 0 2em; }
.card__footer--large { padding: 2em; }

✅ Restricting BEM modifiers to root elements is cleaner

.card--large .card__header { padding: 2em; }
.card--large .card__content { padding: 0 2em; }
.card--large .card__footer { padding: 2em; }

10. Avoid using shorthands if possible

When defining a background color it is very common to just use shorthands like background: gray;. It is important to know, however, that this shorthand reset's all other background properties, like background-position and so on, to initial. Similar case with other shorthands like border and margin.

This causes problems only in the rarest of cases, but if it does, it will be very hard to debug. It is therefore best practice to only change as little as necessary. Be safe and use background-color etc., the prevented headache is worth the extra characters.

🚫 Using shorthands can have unintended side effects

.card {
  background: lightgray;
  border: 0;
  margin: 0 2rem;
}

✅ Using verbose properties helps prevent side effects

.card {
  background-color: lightgray;
  border-width: 0;
  margin-left: 2rem;
  margin-right: 2rem;
}

Further reading: Harry Roberts makes a great case for this in CSS Shorthand Syntax Considered an Anti-Pattern

11. Keep presentation (CSS), semantics (HTML) and behavior (JS) separate

I often see styling tied to ids or elements (like #nav or .nav ul li), or javascript behavior tied to a class (like document.getElementsByClassName(".nav")). However, if you do this you rob yourself of the flexibility to keep presentation (CSS), semantics (HTML), and behavior (JS) separate. You want to be able to style something as a button, regardless if it is an <a>, <button> or <div> (note that the latter is not good for accessibility). Or if you create a navbar, you want to be able to use <li>-tags or <div>-tags depending on the necessary semantics, without losing your styling or have to change the CSS.

To achieve this use ids for javascript (as originally intended), or better, data-attributes like so: document.querySelectorAll('[data-nav]'); and don't mingle the button element selector with your styles. This gives you the freedom to change either semantics, presentation, or behavior independently without having to worry about the other two.

🚫 Bad: mixing presentation and behavior

<button class="btn btn-login">Login</button>

<script>
  const el = document.getElementsByClassName('.btn-login');
  el.addEventListener('click', function (event) { ... }, false);
</script>

<style>
  .btn-login {
    color: white;
    background-color: green;
  }
</style>

✅ Good: presentation and behavior are kept separate

<button class="btn btn-green" data-login>Login</button>

<script>
  const el = document.querySelectorAll('[data-login]');
  el.addEventListener('click', function (event) { ... }, false);
</script>

<style>
  .btn-green {
    color: white;
    background-color: green;
  }
</style>

Exception: There are reasons to use element selectors for styling. For example, if you intentionally set global presets, like a reset or change the default link color. But be careful not to set presets that you find yourself overwriting all the time.

404 Error Page and Redirect with Nuxt

Lukas Hermann — Mon, 28 Sep 2020 05:58:28 +0000

404 Error pages are very easy with Nuxt, but it took me long enough to find a how-to guide that I decided to write my own.

Custom 404 Error Page

The default Nuxt error page, that you probably have seen already, looks like this.

To write your custom error page simply create the file layouts/error.vue. Here is an example:



<template>
  <section>
    <h1>404 Page not Found</h1>
  </section>
</template>

Use the documentation of error pages and the source code of the default error page as reference.

404 Redirect

The above works nicely for routes that don't exist, but sometimes we want to redirect to the 404 page from another page programmatically.

In this example from my personal site Vue checks if the 404-error-page-and-redirect-with-nuxt.md file exists to display the article. If no markdown file is found the user is redirected to the 404 page.

To achieve this I import the error function in my asyncData hook. If the server cannot find the file it forwards to the 404 page with error({ statusCode: 404 }).



export default {
  \\ ...
  async asyncData ({ params, error }) {
    try {
      return await require(`~/writing/${params.slug}.md`)
    } catch (e) {
      error({ statusCode: 404, message: 'Article not found' })
    }
  },
  \\ ...
}

Use the documentation for Handling Errors in asyncData as reference.

How to use Async/Await with Vue.js Components

Lukas Hermann — Tue, 22 Sep 2020 19:22:10 +0000

In the beginning, it can be confusing to handle Vue's opinionated single file templates and how to use the javascript functions you know and love. But fear not, it is very easy.

The Created Hook

The created hook is a lifecycle hook, a method that is called when the template is created for the first time, but before it is mounted.

We can simply declare the created () method as async and perform our asynchronous actions inside. In this example, we are loading a list of users.

Don't forget to handle the null state of users until the data is available. Use v-if="users" in your template or better, add a loading animation{.text-gray-600}

export default {
  data () {
    return {
      users: null,
    }
  },
  async created () {
    const response = await fetch("https://reqres.in/api/users")
    const { data: users } = await response.json()
    this.users = users
  },
}

The Mounted Hook

The mounted hook is almost identical to the created hook but fires after the component was mounted (added to the DOM). The created hook is generally preferred for API calls.

Just like above, we can simply make the mounted () method async.

export default {
  data () {
    return {
      users: null,
    }
  },
  async mounted () {
    const response = await fetch("https://reqres.in/api/users")
    const { data: users } = await response.json()
    this.users = users
  },
}

Methods

Vue allows any method to be an async method. Here is an example with data requested per click on a button.

<button @click="loadUsers">Load Users</button>
<div v-if="users">{{ users }}</div>

export default {
  data () {
    return {
      users: null,
    }
  },
  methods: {
    async loadUsers () {
      const response = await fetch("https://reqres.in/api/users")
      const { data: users } = await response.json()
      this.users = users
    }
  },
}

Computed Properties

Computed properties are the exception, Vue does not allow them to be async. There are ways to get around this restriction like the vue-async-computed plugin, but this is not a good practice.

If you need an async computed property, then you probably made an architectural mistake in your component. With some experience, it becomes natural to handle computed properties as purely synchronous functions. All async operations should be done in methods.

If you still find yourself needing an async computed property then try using a watcher instead.

Watchers

Watchers can perform async operations when they detect changes in the data. Therefore watchers can cause computed properties to update with asynchronously.

Here is an example where the computed prop returns a count of users. The watcher reloads the user list as soon as the userRoles filter changes.

export default {
  data () {
    return {
      userRoles: ['admin'],
      users: [...],
    }
  },
  watch: {
    async userRoles (newRoles) {
      const query = JSON.stringify(newRoles)
      const response = await fetch(`https://reqres.in/api/users?roles=${query}`)
      const { data: users } = await response.json()
      this.users = users
    }
  },
  computed: {
    userCount () {
      return this.users.length
    }
  },
}

Nuxt & asyncData

Nuxt is a framework on top of Vue that makes the development of server-side rendered applications easier.

Nuxt has a special method called asyncData () that is called before the component is created. This allows the server to pre-render the component before sending it to the client and it allows the client to pre-fetch data before the new component is shown to the user. This is especially interesting with page-level components where data can be fetched before the user even clicks on the next link creating the experience, similar to a mobile app, of instant page navigation.

Be aware that asyncData () doesn't have access to the component's instance and this context, therefore the data must be returned instead.

export default {
  async asyncData () {
    const response = await fetch("https://reqres.in/api/users");
    const { data: users } = await response.json();
    return { users }
  },
  data () {
    return {
      users: null,
    }
  },
}

I would love to hear from you if you liked the article or have any questions
Twitter

Fixing the ERR_TOO_MANY_REDIRECTS error with Wordpress

Lukas Hermann — Sat, 09 May 2020 23:04:06 +0000

Every Wordpress developer sooner or later faces the ERR_TOO_MANY_REDIRECTS problem. You navigate to the correct URL but instead of the Wordpress page you are greeted with an error like this (or a similar depending on the browser):

The Problem

(Jump to the solution)

Let's diagnose

Basically, a miscommunication is happening between your browser and Wordpress that goes something like this:

You can see this unfold in the network tab of your developer console. In Chrome, hit ⌘ + alt + I (F12 or Ctrl + Shift + I on Windows) to open the dev tools panel. Go to the "Network" tab, make sure "Preserve log" and "Disable cache" are checked, and then reload the page.

You will see that your browser requests the page as instructed but gets a response with status 301 which stands for "permanent redirect" telling your browser that the page you are looking for is actually somewhere else. Let's open one of the entries in the list and check for the location response header.

You can see that the location: http://localhost:8081 here is identical to the Request URL: http://localhost:8081. Essentially the browser is asking for http://localhost:8081 but the server is not responding with the page but telling the browser to look in another location. So the browser doesn't know any better than to ask for the page in this "other" location, which is really the same URL all along. This is called a redirect loop. Eventually, your browser gets tired and gives up with a TOO_MANY_REDIRECTS error.

Note that http://localhost:8081 is a development server on my local computer which I use to reproduce the problem. In your case, it may be https://phaserbeam-computers.com or so.{.text-gray-600}

So why does the server give this response?

In 9 out of 10 cases this problem is caused by a reverse proxy. A reverse proxy is a server that sits in between your browser and Wordpress. This may have a variety of reasons, in my case, it is a webpack dev server, in your case, your hoster may use Nginx as a webserver for its ease and speed but reverse proxy the request to an Apache server so Wordpress can make use of the familiar .htaccess file and the mod_rewrite module.

Whatever the setup, in reality, the above conversation looks more like this:

By asking for https://example.com your browser is actually talking to a middleman (the reverse proxy) who then, in turn, asks for the server with Wordpress at another location. Wordpress usually deals with this very well except if the middleman changes the port, then Wordpress seems to panic.

Log in to your webserver via SSH or FTP and add the following lines to your wp-config.php file somewhere above the /* That's all, stop editing! Happy publishing. */ line:

print_r($_SERVER);
die();

With these two lines, we instruct the server to print the $_SERVER variable and then stop any further execution. When you now reload the page you should see some gibberish on the screen that looks like this:

Note: without the die(); the server continues execution of Wordpress' PHP files and the gibberish we want to see gets drowned by other stuff. By using it we only get the variable dumped on the screen.{.text-gray-600}

Array
(
    [HTTP_X_FORWARDED_HOST] => example.com
    [HTTP_X_FORWARDED_PROTO] => https
    [HTTP_X_FORWARDED_PORT] => 443
    [HTTP_X_FORWARDED_FOR] => 93.184.216.34
    ...
    [HTTP_HOST] => localhost:8000
    [REQUEST_SCHEME] => http
    [SERVER_PORT] => 8000
    [SERVER_ADDR] => 127.0.0.1
    ...
)

In this fictional case, the example.com wordpress site sits behind a reverse proxy. Originally the browser asked for https://example.com on port 443 (the default port for https is 443 and for http is 80). But the reverse proxy forwards the request to some internal server on localhost with port 8000.

Wordpress usually ignores the discrepancy between example.com and localhost but it gets really worked up on the port 8000. See, if Wordpress wants to serve its page securely over HTTPS, something every modern page should do, it will expect https as request scheme and 443 as the port. But it got http and 8000. Thus it thinks the browser did a request for http://example.com and will respond with a "301 Moved Permanently" to https://example.com (note the s in https).

But for your browser, this is exactly the same URL he just asked for.

The Solution

We must tell Wordpress he facts of the original request from the browser before the reverse proxy middleman messed things up for us.

Fortunately, with the HTTP_X_FORWARDED headers, the reverse proxy is kind enough to tell Wordpress what the browser originally asked for. We can look for these headers and then clear things up for Wordpress.

If you have the common problem that you get the redirect error because you want to use the secure HTTPS instead of the insecure HTTP, then add these lines to your wp-config.php:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
  $_SERVER['HTTPS'] = 'on';
}

Note: The wp-config.php should be in your Wordpress root directory. Add the PHP snipped somewhere above the /* That's all, stop editing! Happy publishing. */ line{.text-gray-600}

If, however, you are like me and get the error because you are using a webpack dev server or some other more complex setup, this snipped should do the trick:

if (isset($_SERVER['HTTP_X_FORWARDED_HOST']) && isset($_SERVER['HTTP_X_FORWARDED_PORT'])) {
  $_SERVER['HTTP_HOST'] = $_SERVER["HTTP_X_FORWARDED_HOST"];
  $_SERVER['SERVER_PORT'] = $_SERVER["HTTP_X_FORWARDED_PORT"];
}

In any case, it is important to specify exactly at what URL Wordpress is available. You can do this inside the Wordpress settings, but I usually prefer to add these two lines to my wp-config.php:

define('WP_SITEURL', 'https://example.com');
define('WP_HOME',    'https://example.com');

When you debug and test solutions regarding 301 permanent redirects make sure to clear your browser cache or keep the developer tools open with the "Network" tab and "Disable cache" checked.

And with that, you should be good to go.

Your Solution doesn't work for me

Then your problem is not a reverse proxy or you have an additional misunderstanding within Wordpress. I have seen cases where the redirect loop alternated between https://example.com/ and https://example.com.

Check your plugins and your .htaccess file. To troubleshoot I usually deactivate all plugins and if the error goes away reactivate them one by one until the troublemaker is found.

Read the Let's diagnose part and check the networks tab of your developer tools to see precisely which redirects the server responds with. Among the response headers, there is also a Server entry that often helps to identify which part of your web server is responsible for the redirect. For example, it may be your "Yoast" plugin.

Vue.js Pattern for Async Requests: Using Renderless Components

Lukas Hermann — Sun, 04 Aug 2019 19:32:04 +0000

Most Vue apps need asynchronous HTTP requests and there are many ways to realize them: in the mounted() lifecycle hook, in a method triggered by a button, within the store (when using vuex) or in the asyncData() and fetch() methods (with Nuxt).

While a simple request is very easy with axios, we usually want to cover at least two additional states:

Show something to the user while the request is pending
Handle errors gracefully

Handling these states adds additional code and can quickly lead to code-duplication when having to implement many different requests.

Origin of the Idea
HTTP requests: A typical example
The Async Renderless Component
- Why not a mixin or directive?
- An applied example

To cut right to the meat, jump to The Async Renderless Component.

Note: Axios is used to make HTTP requests in this example, but it works just as well with any other library for AJAX requests. Also, this example uses this wonderful free Dog API: https://dog.ceo/dog-api/ 🐶.

Origin of the Idea

The idea is not my own, but borrowed from Vue.js creator Evan You @youyuxi who voiced it secondarily while talking about Advanced Vue Components with Adam Whatan on the Full Stack Radio Podcast during Episode 81.

HTTP request in Vue Components: A typical example

Let's start with a minimal example to request a random dog image. The mounted() hook contains the axios call which populates the image variable.

Vue.component("example", {
  el: "#example",
  data() {
    return {
      image: null
    };
  },
  mounted() {
    axios
      .get("https://dog.ceo/api/breeds/image/random")
      .then(function(response) {
        this.image = response.data;
      });
  }
});

Simple enough. However, we want to show a loading animation and handle request errors. So in addition to the image variable pending: false and error: null are added. The mounted() hook then looks as follows:

Vue.component("example", {
  [...]
  mounted() {
    this.pending = true;
    axios
      .get("https://dog.ceo/api/breeds/image/random")
      .then(function(response) { this.image = response.data })
      .catch(function(error) { this.error = error })
      .finally(function () { this.pending = false });
  }
});

Now a loading indicator can be shown for pending === true and a basic error message can be displayed if error !== null. It's really simple, but it can get tedious to implement this pending/success/error behavior repeatedly. Besides, if the request contains parameters that can be changed by the user, e.g. filters or sorting options, then the request has to move to a method which has to be called, whenever the parameters changes, to reload the data.

One easy and effective way to abstract away this simple behavior and make it reusable is ...

The Async Renderless Component

This component makes use of the incredibly versatile Scoped Slot feature. A slot is any piece of HTML that can be passed to a component, telling the component: "Here, render this somewhere". With scoped slots the component which receives the HTML snipped answers: "Awesome, I will put your HTML right there. And here is some data you can use with your snipped if you like".

The Async Renderless component is just such a component that receives a snippet of HTML, a URL and parameters and answers: "Hey look, I am requesting this data for you, here is data, pending and error for you to use."

The Async Renderless Component in full:

Vue.component("async", {
  props: {
    url: { type: String, default: "", required: true },
    params: { type: Object, default: () => ({}) }
  },
  data() {
    return {
      pending: true,
      error: false,
      data: null
    };
  },
  watch: {
    url() {
      this.requestData();
    },
    params: {
      handler() {
        this.requestData();
      },
      deep: true
    }
  },
  mounted() {
    this.requestData();
  },
  methods: {
    async requestData() {
      this.pending = true;
      try {
        const { data } = await axios.get(this.url, { params: this.params });
        this.data = data;
        this.error = false;
      } catch (e) {
        this.data = null;
        this.error = e;
      }
      this.pending = false;
    }
  },
  render() {
    return this.$scopedSlots.default({
      pending: this.pending,
      error: this.error,
      data: this.data
    });
  }
});

Note: I am using some javascript magic here: Arrow Functions, Async/Await and try...catch.

The "renderless" happens in the render() tag. Instead of an HTML tag, these components only renders the HTML snippet it receives in its slot as scoped slot, passing three data points to it: pending, error and data.

The watch functions make sure that the data is reloaded whenever either url or params change.

We use the async component inside our template like this:

<async url="https://dog.ceo/api/breed/husky/images">
  <template v-slot:default="{ pending, error, data }">
    <div v-if="pending">Loading ...</div>
    <div v-else-if="error">{{ error }}</div>
    <div v-else>{{ data }}</div>
  </template>
</async>

Why a renderless component and not a mixin or directive?

Components are not the only way to reuse code in Vue, another way is to use a Mixin or a Custom Directive. Both are fine ways to solve this problem. Renderless components utilizing scoped slots are operating the way Vue wants to work, it can be imported when needed just like you are used to with any other component. Thus it's a very explicit way to reuse code as opposed to mixins or directives which don't have to be included separately. In the end, it comes down to preference.

An applied example

I constantly find myself implementing lists when working with APIs which usually feature things like pagination, filters, sorting and search. So I decided to put together a "real-life" example which renders a simple list of dog images with a very simple filter option for some different breeds (and a wrong API call to see the error state):

Whenever one of the filter buttons is clicked the URL, which is passed to the async component, is updated with the appropriate breed. The async component takes care of the HTTP request. No more HTTP request logic is needed in the parent component, separation of concerns is obeyed, our minds are freed and the universe is in harmony 😄.