DEV Community: Márk Munkácsi

Shrink image on client side in browser

Márk Munkácsi — Thu, 05 Nov 2020 21:41:59 +0000

The problem

We needed to handle file uploads properly on the frontend. I know it's not a client side stuff to handle images, without proper library, but that was the requirement, and hey, it's an interesting task!🤔

So the exact problem was, how can I downsize the image to a given filesize (let's say 1MB). The steps are not a compicated ones, just need to render the selected image, then check it's size. If it's bigger than 1MB we need to shrink it by some pixels, then check it's size again, and do this recursion until it's size matches to our requirement (<= 1MB).

I will provide the code with a working example at the end in one piece, maybe in this way have more sense like showing it in chunks. So if you just need to copy it and go, scroll down.😀

First steps - HTMLImageElement

I started to looking for web APIs how can they help me. That was clear I need to use image element to handle images in memory. Sounds good at first try, I can get width and height of the image, these will be crucial to calculate the ratio. Also I know the size of the uploaded file, since File have this property. The next problem is, if it's too big, I need to shrink it.

Digging into - Canvas

To shrink a given file I will need to use the Canvas API. Using canvas's 2D context I can render the shrinked image by decrease it's dimensions. I will need to keep the ratio here. After rendering, I can get rendered image again from canvas as File, and I will be able to tell it's size and (after creating an Image from it) it's dimensions as well, to shrink it again if it's needed.

Performance

This process isn't optimal, but as I mentioned, on client side we don't have proper tools or libraries to handle operations with images. There is two thing to increase the performance, one of them is downsizing step. It affects the number of iterations, so the bigger is the better, but if it's too big it might affect efficienty. The second one is the calling of this function. Since it's returning a Promise you can handle multiple processes paralelly with Promise.all() but I recomend to do it in serial way. In the next section I will tell you why...

The iOS Safari bug

There is a bug which showed up when I tested the code on iOS. It said me: Total canvas memory use exceeds the maximum limit (224 MB). Apple allows to use only WKWebView, which means you can use other browsers on platform than Safari, but they uses the same engine, so maybe this issue affects not just Safari but the whole platform. TLDR: there is a garbage collection issue with WebKit that causes memory limit exceeding. Here is the issue about it: https://bugs.webkit.org/show_bug.cgi?id=195325. The workaround was here to use only one canvas element and just update it in every recursion, it makes code harder to understand, but in this way I can avoid memory leak.

Final words

I tested the code only in Firefox on Desktop and in Safari on mobile with ~7MB images. Maybe it isn't bulletproof and its a bit slow, but that is the best what we can do on frontend. I always recommend to handle images on server side and just check file limits on client side.

And finally here comes the code.🙃

Thanks for reading and don't forget to drop a unicorn if you liked it.🦄

Styled Range Input - A way out of Range Input nightmare

Márk Munkácsi — Wed, 01 Apr 2020 02:01:27 +0000

Did you ever faced with range inputs? They are really simple, right? You can pass min and max, perhaps step as you can see below.

<input type="range" min="100" max="200" step="10">

But what if you need to create custom styled range input? Here comes the pain.

⬇️ tldr; if you just want the code, scroll down.

So, the range input have three parts. And if you want to implement it for yourself, probably you will use the same three parts as <div>s with a plenty of JavaScript magic, mouse event handling and calculating the value out of relative sizes and positions.

Trackbar, Progressbar, Thumb.

There are a lot of articles in the wild about styling range inputs. Maybe the most comprehensive articles about this topic are from 2017.

So we have the three parts, let's start with Thumb. It's a simple button-like draggable thingie. Unfortunately we need to use different prefixes like in old times for browser compatibility.

input[type="range"]::-webkit-slider-thumb {
  /* Styles for Chrome */
}
input[type="range"]::-moz-range-thumb {
  /* Styles for Firefox */
}
input[type="range"]::-ms-thumb {
  /* Styles for IE */
}

The following can be the Trackbar which is the range what Thumb can slide on. Here we have another three pseudo elements for browsers.

input[type="range"]::-webkit-slider-runnable-track {
  /* Styles for Chrome */
}
input[type="range"]::-moz-range-track {
  /* Styles for Firefox */
}
input[type="range"]::-ms-track {
  /* Styles for IE */
}

Great, but can we create a Progressbar for it? Sure, let's see following:

input[type="range"]::-moz-range-progress {
  /* Styles for Firefox */
}
input[type="range"]::-ms-fill-lower {
  /* Styles for IE */
}
/* Styles for Chrome... ¯\_(ツ)_/¯ */

Yep, that's all folks, Chrome don't have styling for Progressbar. Although you can implement a moderately ugly workaround using CSS calc() function, which is well supported in modern browsers. Besides CSS you will need some JS magic. The sad news are, pseudo elements can't be reached from JavaScript, but you can set CSS variables with it. Let's see the magic. You need to change only WebKit related styles of Trackbar.

input[type="range"] {
  --webkitProgressPercent: 0%;
}
input[type="range"]::-webkit-slider-runnable-track {
  background-image: linear-gradient(
    90deg,
    #f2f2f2 var(--webkitProgressPercent),
    #262626 var(--webkitProgressPercent)
  );
}

Now you only need to attach the --webkitProgressPercent variable to Thumb's position. Here you will need to listen to some mouse events to achieve the native functionality. Rather I will attach here a working example which includes JS functionality as well.

PS, I didn't tested it in IE, only in Chrome and Firefox. I created a React component for this issue as well.

Now you are out of Range Input nightmare!😁

I hope this article was helpful for you, if you have a question or suggestion, let's discuss it in comments. And don't forget to like it. 🙏

Ways to create a new Chrome instance without CORS [macOS]

Márk Munkácsi — Sun, 06 Oct 2019 21:42:01 +0000

This tutorial is mainly for macOS users, but the command line stuff can be useful for everyone.😊

When you need to test your code in Chrome with default settings and without extensions, the --user-data-dir argument will be your friend. There is another flag for disable CORS: --disable-web-security. Before running the command, you might kill all Chrome instances.

From command line

Open your Terminal app and just run the following.

$ open -n -a /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --args --user-data-dir=/tmp/chrome_dev_test --disable-web-security

A new Application

On macOS you can easily create an Automator app, so open it, create a New Document then select the Application.

After that, search for the Run Shell Script action and put the bash script from previous section inside it. Then save it with ⌘S.

From Visual Studio Code debugger

First of all you need the Debugger for Chrome extension. In debug menu (⇧⌘D) add a new configuration with Chrome target. Here you can set your localhost port and add new fields. In the configurations field should be the following. Then just save it and run it.🚀

{
  "type": "chrome",
  "request": "launch",
  "name": "Launch Chrome against localhost",
  "url": "http://localhost:8080",
  "webRoot": "${workspaceFolder}",
  "userDataDir": "/tmp/chrome_dev_test",
  "runtimeArgs": ["--disable-web-security"],
  "sourceMaps": true
}

Follow me here or on Twitter for random dev stuff like this.😁

Asynchronicity in JavaScript

Márk Munkácsi — Wed, 04 Sep 2019 13:01:06 +0000

When things can happen independently of the programs main thread, we're talking about asynchronicity. By default JavaScript is a synchronous single threaded language which means it cannot run multiple threads parallelly. Your code will be executed from top to bottom, one after another. But what if you need to do some heavy computation on client side or just to wait for a long server response? The UI freezes until it's done, no clicks, no scrolling, no animations.

JavaScript (as it's name suggests) is a high-level, interpreted scripting language running in a browser by it's engine. For more information about engines, here is Geckos and V8s homepage. Browser provides features that can handle asynchron functionality. Web APIs, the event loop, the task queue are not part of the JavaScript engine. For deeper understanding of how event loop works check this great video.

Callbacks

A callback is a function which is passed to another function as a parameter. The simplest example for a callback is handling a button click. You need to listen for the click event, and when it happens, the browser will exectute the given function (the callback).

const button = document.getElementById('button');
const myCallback = () => alert('Click happened');

button.addEventListener('click', myCallback);

This way you can handle asynchronous server requests as well.

const request = new XMLHttpRequest();
const myCallback = event => console.log(event.target.response);

request.addEventListener('load', myCallback);
request.open('GET', 'http://www.example.org/example.txt');
request.send();

Callbacks are good for simple cases like handling a button click. The pain starts when you need to nest callbacks, and wrap logics into. It's called "Callback Hell" or "The Pyramid of Doom". For example let's wait for page load, then listen for the button click and when the button was cliked do a server request, then log it to the console.

window.addEventListener('load', () => {
  document.getElementById('button').addEventListener('click', () => {
    const request = new XMLHttpRequest();
    request.addEventListener('load', (event) => {
      console.log(event.target.response);
    });
    request.open('GET', 'http://www.example.org/example.txt');
    request.send();
  });
});

Promises

In ES6 there is a new feature called Promise. It's an object representing the eventual completion or failure of an asynchronous operation. It's constructor waits an exectutor function with parameters "resolve" and "reject". You can use the "then" method as fulfillment and rejection handler, "catch" for handle only rejection and "finally" for run code when promise is done. For example let's wrap a timeout into promise.

const myPromise = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve('Hello from promise');
  }, 2000);
});

myPromise.then(returnedValue => console.log(returnedValue));

Promises are handy when you need to nest asynchronous parts but want avoid the Callback Hell. In this example I'll use Fetch API which returns a Promise. Let's create a snippet with a timeout. After that do a server request and then log the data out.

const timeout = () => new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve('Hello from promise');
  }, 2000);
});

const request = () => fetch('http://www.example.org/example.txt')

timeout()
  .then(request)
  .then(response => response.json())
  .then(data => console.log(data));

Async/Await

ES7 brings async and await syntax which are just syntactic sugar over Promises. "await" can only be used inside an async function. With them you can wait for promises with a very clear readable syntax. Let's refactor the code from above with async/await.

const timeout = () => new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve('Hello from promise');
  }, 2000);
});
const request = async () =>
  await fetch('http://www.example.org/example.txt');

await timeout();
const request = await request();
console.log(request.json());