DEV Community: Sebastian Stamm

I made an outdoor adventure game to motivate me to go outside more

Sebastian Stamm — Sat, 03 Sep 2022 09:25:05 +0000

I was bored with the usual routes for my daily walk, so I made a "Random Adventure Generator" that creates a bunch of random coordinates to reach. When you reach one of the coordinates you level up and then a new set of coordinates is generated. For the first level there are a bunch of coordinates nearby, but for later levels you need to travel farther and since it's all random, you will explore places you probably have never been to.

Here is the link to the game: https://earthquest.net

The locations of the randomly generated coordinates change every day so that you can go outside every day and have a new experience and discover new places. Also, all players have the same coordinates, so when playing with your friends, you all can go to the same places!

I made a small trailer video (Animations and all are also pure Javascript):

Before building EarthQuest, I played some other geolocation games, but was always annoyed that they require a lot of interaction. Maybe it's just me, but I find it awkward to stand around outside and having to interact with my phone for several minutes before moving on to the next goal. So for EarthQuest it's just: "Go to this coordinate; touch the Level Up button; Go to the coordinate for the next level". This let's you focus on your surroundings and get moving.

The game runs completely in the web browser. At first I was considering building a native app, but with the Geolocation API I can just use plain old Javascript. And as an additional bonus I don't have to deal with the walled gardens that are the app stores. Plus, it's a PWA (Progressive Web App), so you can still install it on the Homescreen.

This is one of my most ambitious projects so far, so please try it out and let me know what you think!

Be careful with console.log when using React.StrictMode

Sebastian Stamm — Sat, 05 Dec 2020 11:32:31 +0000

I recently came across an interesting phenomenon that can be reproduced with this minimal example:

let i = 0;

function App() {
  i++;
  console.log("render count:", i);
  return i;
}

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById("root")
);

A novice developer might look at this code and think:

Okay, we are rendering the App component, this increases the i counter, prints it to the console and returns it. So the result is "render count: 1" in the browser log and 1 is rendered on screen.

A more experienced developer knows that React.StrictMode causes the render function to be called twice. The idea is that this will help developers identify unintended side-effects in methods that should be side-effect free. You can read more about that here: https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects

So they might say:

React intentionally calls the render function twice, so i will be increased twice. We will see two entries in the browser console "render count: 1" and then "render count: 2" and the screen will render 2.

If you run this code however, there is only one console log saying "render count: 1", but the screen shows 2. You can see this for yourself here: https://codesandbox.io/s/strict-mode-logs-pynlw?file=/src/index.js

What is going on?

The only place where the value of i is increased is directly followed by a console.log statement, so if i would be set to 2, it should show up in the console.

It turns out that React is hijacking console.log and is replacing it with a function that does nothing on the second render pass. Here is the code that does that, this is the Pull Request that introduced this behavior and here is an open Pull Request to add an opt-out option to the dev tools.

In our example the render function is indeed executed twice, which leads to i being 2 when it is rendered on screen, but only the first console.log call actually logs to the console so it looks like the render function is only called once and i is only set to 1.

Personal Opinion

My personal opinion is that the decision to disable the logs for the second render pass was wrong. Developers not familiar with StrictMode will try to use console.log debugging to figure out why their functions are executed twice. If the logs for the second pass don't show up in the console, developers might falsely assume that the function is only executed once.

I would even argue that it undermines the concept of StrictMode. Printing to the console is a side-effect that StrictMode is supposed to expose. Intentionally obscuring it not only makes debugging harder, it prevents developers finding rogue log statements in render phase lifecycle methods that could cause problems in production once concurrent mode lands.

This Image Is Also a Valid Javascript File

Sebastian Stamm — Sun, 06 Sep 2020 08:39:12 +0000

Images are usually stored as binary files, while a Javascript file is basically just text. Both have to follow their own rules: Images have a concrete file format, encoding the data in a certain way. Javascript files have to follow a specific syntax in order to be executable. I wondered: Can I create an image file that has valid Javascript syntax, so it is also executable?

Before you read on, I highly recommend checking out this code sandbox with the result of my experimentation:

https://codesandbox.io/s/executable-gif-8yq0j?file=/index.html

If you want to check out the image and inspect it yourself, you can download it here:

https://executable-gif.glitch.me/image.gif

Choosing the Right Image Type

Unfortunately, images contain a lot of binary data which will throw an error if interpreted as Javascript. So my first idea was: What if we just put all the image data in a large comment, like this:



/*ALL OF THE BINARY IMAGE DATA*/

That would be a valid Javascript file. However, image files need to start with a specific sequence of bytes; a file header that is specific to the image format. PNG files for example always have to start with the byte sequence 89 50 4E 47 0D 0A 1A 0A. If an image would start with /*, it would not be a valid image file anymore.

This file header lead to the next idea: What if we could use this byte sequence as variable name and have a huge string assignment like this:



PNG=`ALL OF THE BINARY IMAGE DATA`;

We are using template strings instead of the normal " or ' strings because the binary data could contain linebreaks and template strings are better at dealing with those.

Unfortunately, most byte sequences for image file headers contain unprintable characters that are not allowed in variable names. But there is one image format we can use: GIF. The GIF header block is 47 49 46 38 39 61, which conveniently spells GIF89a in ASCII, a perfectly legal variable name!

Choosing the Right Image Dimensions

Now that we found an image format that starts with a valid variable name, we need to add the equals and backtick characters. The next four bytes of the file are therefore: 3D 09 60 04

In the gif format, the four bytes following the header specify the dimensions of the image. We have to fit 3D (the equals sign) and 60 (the backtick that opens the string) in there. GIF uses little endian so the second and fourth character have a huge influence on image dimensions. We want to keep them as small as possible to not end up with an image that is tens of thousands pixels wide. Therefore we store the big bytes 3D and 60 in the least significant bytes.

The second byte of the image width needs to be a valid whitespace character, because this would be the space between the equals sign and the beginning of the string GIF89a= `.... Keep in mind that the hexcode of the characters should be as small as possible, or the image would be huge.

The smallest whitespace character is 09, the horizontal tab. This gives us an image width of 3D 09, which in little endian translates to 2365; a bit wider than I would have liked, but still reasonable.

For the second height byte, we can just choose something that produces a nice aspect ratio. I chose 04, which produces a height of 60 04, or 1120.

Getting our own script in there

Right now, our executable gif does not really do anything. It just assigns a large string to the global variable GIF89a. We want something interesting to happen! Most of the data inside the GIF is for encoding the image, so if we try to add Javascript in there, we would probably end up with a very corrupted image. But for some reason, the GIF format contains something called a Comment Extension. This is a place to store some metadata that will not be interpreted by the GIF decoder - a perfect place for our Javascript logic.

This comment extension comes right after the GIF color table. Since we can put any content in there, we can easily close the GIF89a string, add all our Javascript and then start a multiline comment block, so the rest of the image does not interfere with the Javascript parser.

All in all, our file could then look like this:



GIF89a= ` BINARY COLOR TABLE DATA ... COMMENT BLOCK:

`;alert("Javascript!");/*

REST OF THE IMAGE */

There is a small restriction: While the comment block itself can be of any size, it is composed of multiple sub-blocks, each of which has a maximum size of 255. Between the subblocks is a single byte that indicates the length of the next subblock. So in order to fit a larger script in there, it has to be divided into smaller chunks, like this:



alert('Javascript');/*0x4A*/console.log('another subblock');/*0x1F*/...

The hexcodes in the comments are the bytes that indicate the size of the next subblock. They are irrelevant for the Javascript, but required for the GIF file format. In order to prevent them from interfering with the rest of the code, they have to be in comments. I wrote a small script that processes the script chunks and adds them to the image file: https://gist.github.com/SebastianStamm/c2433819cb9e2e5af84df0904aa43cb8

Cleaning up the Binary

Now that we have the basic structure down, we need to make sure that the binary image data does not ruin our syntax. As explained in the previous section, the file has three sections: The first one is an assignment to the variable GIF89a, the second one is the Javascript code and the third one is a multiline comment.

Let's have a look at the first part, the variable assignment:



GIF89a= ` BINARY DATA `;

If the binary data would contain the character ` or the character combination ${ we are in trouble because this would either end the template string or produce an invalid expression. The fix here is quite easy: Just change the binary data! E.g. instead of using the ` character (hexcode 60), we could use the character a (hexcode 61). Since this part of the file contains the color table, it would result in some of the colors being slightly off, e.g. using the color #286148 instead of #286048. It is unlikely that someone will notice the difference.

Fighting the corruption

At the end of the Javascript code, we opened a multiline comment in order to make sure the binary image data does not interfere with the Javascript parsing:



alert("Script done");/*BINARY IMAGE DATA ...

If the image data would contain the character sequence */, the comment would end prematurely, which would result in an invalid Javascript file. Here again we can manually change one of the two characters so they no longer end the comment. However, since we are now in the encoded image section, this will result in a corrupted image, like this:

In extreme cases the image could not be displayed at all. By carefully choosing which bit to flip I was able to minimize the corruption. Fortunately there were only a handful of instances of the harmful */ combination to deal with. There is still a bit of corruption visible in the final image, e.g. at the bottom of the "Valid Javascript File" string, but overall I am pretty happy with the result.

Ending the File

The last operation we have to perform is at the end of the file. The file has to end with the bytes 00 3B. So we have to end our comment earlier. Since this is the end of the file and any potential corruption would not be very visible, I just ended the multi block comment and added a single line comment so that the end of the file would not cause any problems when parsing:



/* BINARY DATA*/// 00 3B

Convincing the Browser to Execute an Image

Now, after all this, we finally have a file that is both an image as well as a valid Javascript file. But there is one last challenge we have to overcome: If we upload the image to a server and try to use it in a script tag, we would most likely see an error like this:

Refused to execute script from 'http://localhost:8080/image.gif' because its MIME type ('image/gif') is not executable.

So the browser rightfully says "That's an image! I am not going to execute that!". Which in most cases is a good mindset to have. But we want to execute it anyway. Our solution here is to just not tell the browser that it's an image. For that I wrote a small server that serves the image without any header information.

Without the MIME type information from the header, the browser does not know that it is an image and just does what fits the context best: Display it as image in an <img> tag, or execute it as Javascript in a <script> tag.

But ... why?

That is something I have yet to figure out. It was a nice mental challenge to make this stuff work, but if you can think of any scenarios where this might actually be useful, please let me know!

Screen Recording in 10 lines of Vanilla JS

Sebastian Stamm — Sun, 08 Mar 2020 11:13:41 +0000

Let’s have a look at how we can capture and record your users screen. Not just your page, but also other tabs of the users browser, the desktop and even other applications. And we will do that without browser plugins or huge libraries. Instead, we just need 10 lines of Vanilla Javascript.

To achieve this, we will use the Media Capture and Streams API. It’s related to the WebRTC API, but for now we ignore all the peer-to-peer streaming between browsers and just do very bare-bones recording.

Full Example

While we could send the recording to a server to store or process it, for this blog post we just capture it and then play it back to the user in a <video> tag. You can find the complete example here: https://codesandbox.io/s/sharp-mestorf-qumzf.

To try it out, click the "Start Recording" button, select which screen you want to share, perform some actions and then click the "Stop Recording" button.

You might notice that the example contains more than 10 lines of Javascript. This is because it also contains a bit more code to deal with the start and stop buttons. The recording logic can be found in the startRecording function, starting from line 6. In summary, this function performs these three steps:

Create a video stream of the users desktop
Record this stream
Convert the recording to transmit it to the server or show it in the <video> tag

Let’s look at each step in detail:

Create a Video Stream

const stream = await navigator.mediaDevices.getDisplayMedia({
  video: { mediaSource: "screen" }
});

It’s just a single function: getDisplayMedia. Calling this opens a dialog for the user to choose which screen to record from (if they have multiple displays). They can also choose to just record a specific application or browser tab. Two things to keep in mind here: The user has to actively allow the sharing, so you cannot use this feature to spy on your users. Also, it returns a promise, so make sure to await it.

Record the Stream

const recorder = new MediaRecorder(stream);

const chunks = [];
recorder.ondataavailable = e => chunks.push(e.data);
recorder.start();

Here, we use the MediaRecorder API to capture the stream we got from the previous step. Since video streams can get quite big, the recorder can periodically call ondataavailable. For now, we store each video chunk in an array and will deal with it in the next step. After setting up the data handling, we start the recording.

Convert the Recording to a Blob

recorder.onstop = e => {
  const completeBlob = new Blob(chunks, { type: chunks[0].type });
  video.src = URL.createObjectURL(completeBlob);
};

At some point, we need to call recorder.stop(); In the example, this happens when you click the "Stop Recording" button. This will call the onstop event handler of the recorder. There we take the chunks from the previous step and convert them into a Blob. And then you can do whatever with it.

You could send it to your server as part of your "Submit Feedback" functionality. You could upload it to Youtube. Here, we just play the recording back to the user by constructing an object url and using it as src attribute for the video tag.

And there we have it, with just 10 lines of Javascript (plus a little bit more for the recording controls), we were able to capture the users screen. I trust you to use this power for good, not evil.

This blog post is written entirely in the <head>*

Sebastian Stamm — Mon, 09 Sep 2019 18:36:01 +0000

*Unfortunately, dev.to embeds blog posts in the body, so you need to click here to enjoy the true <body>-less experience. I also embedded it below for your convenience:

Debugging Challenge: The cursed default clause

Sebastian Stamm — Mon, 02 Sep 2019 16:41:29 +0000

An evil witch cursed my switch statement so that no matter what I put in, it always executed the default clause instead of the case clauses.

This is a problem that I encountered in real life and is still my favorite bug. Here is a minimal setup you can play around with: Check it out on codesandbox.io

Can you find out what is going on? I had an enlightening aha-moment when I figured it out, so I encourage you to have a look! The rest of this post describes the problem and why it behaves this way. If you want to find it out yourself, stop reading here.

What is going on?

function handleError(error) {
  switch (error) {
    case 404:
      console.log("Document not found");
      break;

    case 500:
      console.log("Server Error");
      break;

    default:
      const error = {
        msg: "Got an unknown error code",
        timestamp: Date.now()
      };
      console.log("Unknown Error Incident", error);
  }
}

handleError(404); // should log "Document not found", but logs “Unknown Error Incident”

No matter what you call the function with, it always executed the default clause. Which is weird because there are cases that cover the inputs for the other values, so in those cases it should not go to the default clause.

You will notice however, that the code itself is fine. If you copy it into your browsers console and execute it, you will see that it goes into the case clause if necessary and only uses the default if none of the case clauses match.

The problem is not the code that is written, but the code that is executed.

Most projects use something called a transpiler. A transpiler takes Javascript code and compiles it to other Javascript code. This is so you can write fancy modern Javascript with all the cool new features and still have it run in Internet Explorer.

Which is a really awesome concept, but it also adds another layer of abstraction that can cause subtle bugs in your code. This is exactly what happened here. This is the code that is actually executed after transpilation:

function handleError(error) {
  switch (_error) {
    case 404:
      console.log("Document not found");
      break;

    case 500:
      console.log("Server Error");
      break;

    default:
      var _error = {
        msg: "Got an unknown error code",
        timestamp: Date.now()
      };
      console.log("Unknown Error Incident", _error);
  }
}

handleError(404); // should log "Document not found", but logs “Unknown Error Incident”

Looking at this code it’s instantly clear that this can’t work as the switch uses a variable that is not initialized yet. This is an actual bug in the transpiler: https://github.com/babel/babel/issues/5378

If we rename the error variable in the default clause, everything works as it should even in the transpiled code.

How to debug this

Fortunately bugs like this are quite rare. And now that you are aware that transpilers can cause such problems you are already one step closer to identify and fix them.

One simple step you can take to run the untranspiled code in the browser console. Most of the time you need to simplify your code to isolate it from your business application, but constructing a minimal test case is a good practice anyway.

The other way is to inspect the transpiled source code. In the chrome console you can click on the “sourcemapped from” link to see what is actually executed.

Did you ever encounter a bug that made you scratch your head before discovering a surprising solution? I’d love to read about them! Also, since this is my first blog post, if you have any thoughts or suggestions on how I could improve, please share them with me, too!