# 03.17.2022 - JavaScript/Partial update an object in IndexedDB

Let's say, you have the object store called **characters** as the following table:

| Key | Value |
|:----|:------|
|1    | { **name**: "Bilbo Baggins", **race**: "Hobbits" } |
|2    | { **name**: "Legolas Greenleaf", **race**: "Elves" } |

To update a record, we can use [`IDBObjectStore.put()`](https://developer.mozilla.org/en-US/docs/Web/API/IDBObjectStore/put) method, but this will update the value object as a whole.

In case you want to change just the `name` of record #1, from "Bilbo" to "Frodo", you will need to create a [Cursor](https://developer.mozilla.org/en-US/docs/Web/API/IDBCursor) to find the record #1, and use [`IDBCursor.update()`](https://developer.mozilla.org/en-US/docs/Web/API/IDBCursor/update) method to make an update:

```typescript
const transaction = db.transaction(['characters'], 'readwrite');
const store = transaction.objectStore('characters');

store.openCursor().onsuccess = event => {
    const cursor = event.target.result;
    if (cursor) {
        if (cursor.value.name === 'Bilbo Baggins') {
            const updateData = cursor.value;
            updateData.name = 'Frodo Baggins';
            
            cursor.update(updateData);
        }
        cursor.continue();
    }
};
```



Partial update an object in IndexedDB

# 03.16.2022 - JavaScript/Moving from LocalStorage to IndexedDB

LocalStorage is a popular solution to persists data (locally) across sessions for web applications, but there are some limitations, for example:

- It is limited to 10MB on most browsers. On Safari, it's 5MB
- It can only store DOMString data (for both key and values). If you have a complex object, you have to encode it, for example, using `JSON.stringify`.
- It's blocking, while the data is writing or reading, your code blocks
- It can't be used in web workers, so you cannot move the intensive data handling task off the main thread.

On the other hand, IndexedDB free you up from some of the LocalStorage's limitations:

- You can use up to 50% of the free disk space (on Firefox), or 80% on Chrome. The limit is 1GB on Safari, but there will be 200MB increments every time you hit the limit.
- It can store any object, File, or ArrayBuffer. So, no more `JSON.stringify`.
- Writing and reading are asynchronously (but IndexedDB does not provide any Promise interface, more on this later)
- It can be used in web workers!

The downside is the API of IndexedDB is cumbersome, while it's not providing any Promise interface, you have to create a handler to handle every event for every operation, for example, to open a DB:

```typescript
let db;

const  request = indexedDB.open("TestDatabase");

request.onerror = event => {
    ...
};

request.onsuccess = event => {
    db = event.target.result;
};

request.onupgradeneeded = event => {
    db = event.target.result;
    // object store a.k.a tables, can only be created
    // inside onUpgradeNeeded
    var objectStore = db.createObjectStore("table-name");
};
```

The same with reading or writing data:

```typescript
const request = db
    .transaction(["table-name"])
    .objectStore("table-name")
    .get(<key>);

request.onsuccess = event => {
    // request.result
};
```

For a more detailed introduction on how to use the IndexedDB APIs, check this document https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB

Also, on Safari, there is a [7 days limit](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) to store any data, regardless of LocalStorage or IndexedDB.

It's also important to note that all client-side storage solutions should only be used to store non-sensitive data. Any script running on the page can access them.

---

To make things easier when using IndexedDB, there are a lot of libraries that wrap the IndexedDB API and provide the Promise-based interface, like [IDB](https://github.com/jakearchibald/idb) or [localForage](https://github.com/localForage/localForage).

To replace localStorage in your project with IndexedDB, you can mimic the API of localStorage, like `setItem`, `getItem`, and wrap it with IDB, or use localForage directly.

Below is the localStorage-like interface implemented using IDB:

```typescript
import { openDB } from 'idb';

const DB_NAME = "localStorage-DB";
const TABLE_NAME = "keyValuesStore";

const DB = async () => await openDB(DB_NAME, 1, {
    upgrade(db) {
        db.createObjectStore(TABLE_NAME);
    }
});

export const Storage = {
    get: async (key) =>
        (await DB()).get(TABLE_NAME, key),
    set: async (key, value) =>
        (await DB()).put(TABLE_NAME, value, key),
    del: async (key) =>
        (await DB()).delete(TABLE_NAME, key),
    clear: async (key) =>
        (await DB()).clear(TABLE_NAME),
    keys: async () =>
        (await DB()).getAllKeys(TABLE_NAME)
};
```

Then you can go and replace your localStorage usage with the new Storage:

```diff
- localStorage.setItem('key-001', JSON.stringify(value));
+ Storage.set('key-001', value);

- const obj = JSON.parse(localStorage.getItem('key-001') ?? '{}');
+ const obj = Storage.get('key-001');
```

You can check the following documents for more detailed information on IndexedDB and other storage solutions for web apps:

- https://github.com/jakearchibald/idb
- https://github.com/localForage/localForage
- https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/indexeddb-best-practices
- https://web.dev/storage-for-the-web/
- https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API
- https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB
- https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
- https://www.rdegges.com/2018/please-stop-using-local-storage/

Moving to IndexedDB

# 02.18.2022 - JavaScript/Beware the delete

Unlike C/C++, the [delete](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete) operator in JavaScript has nothing to do with memory deallocation.

What it actually does is **remove a property from its parent object**. If there is no more reference to that property, it will be marked as [unreachable](https://javascript.info/garbage-collection#reachability) and will be released when the garbage collector (GC) runs.

In the following example, delete `foo.b` will mark the string "yolo" as unreachable, and it will eventually be released from the memory:

```javascript
let foo = {
    a: 12,
    b: "yolo"
};

delete foo.b;

// foo = { a: 12 }
```

![](_meta/delete-object-prop.png)

But in a scenario when two objects shared the same reference, things might not work as you expected.

```javascript
let boo = { c: true };

let foo = {
    a: 12,
    b: boo
};

let bar = {
    b: boo
};

// foo = { a: 12, b: { c: true } }
// bar = { b: { c: true } }

delete foo.b;

// foo = { a: 12 }
// bar = { b: { c: true } }
```

![](_meta/delete-object-with-ref.png)

The string `boo` is shared between `foo` and `bar` as the property `b`, when you delete the reference `foo.b`, the string `boo` is still being referenced in `bar.b`, so it's still reachable. Hence, nothing will be deleted when the GC runs.

---

In strict mode, when the `delete` command is called and the target could not be deleted, a `SyntaxError` will be thrown. If running in non-strict mode (also known as [sloopy mode](https://developer.mozilla.org/en-US/docs/Glossary/Sloppy_mode)), a `false` value will be returned instead.

When a property is created as [non-configurable](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete#non-configurable_properties), it cannot be deleted, and a `TypeError` will be raised instead.

```javascript
'use strict';

var bar = {};
Object.defineProperty(bar, 'hello', { configurable: false });
delete bar.hello; // TypeError


var foo = {};
Object.defineProperty(foo, 'goodbye', { configurable: true });
delete foo.goodbye; // this works fine
```

A variable defined with `var` is either belongs to a scope of the function it's defined in, or the global scope (if not defined inside any function).

When defined in the global scope, a variable is added as a non-configurable property to the global object. So, it cannot be deleted.

```javascript
'use strict';

// global scope
var hello = "world";
delete globalThis.hello; // Type Error
delete hello; // Syntax Error, see below
```

Also, in strict mode, if `delete` is used on a direct reference to a variable, function argument, or a function name, it also throws a Syntax Error:

```javascript
'use strict';

var b = 'xyz';
delete b; // Syntax Error

let c = "hello";
delete c; // SyntaxError:

const d = 15;
delete d; // SyntaxError

function hello(x) {
    delete x; // Syntax Error
}

function hello() {}
delete hello; // Syntax Error
```

Deleting a variable defined with `var` inside a function is also does not works:

```javascript
'use strict';

function hello() {
    var x = "what's up?";
    delete x; // Syntax Error
}
```

---

In non-strict mode, if you define a variable without the `var` keyword, it will be added to the global object as configurable, hence, we can delete it:

```javascript
awesome = true;
delete awesome; // true
```

And if you delete something that does not exist, it also returns true!

```javascript
delete somethingDoesNotExist; // true!!!
```

---

Did you hate the `delete` yet? Let me make you hate it more.

If you `delete` an element from an array, it will be gone, but the length of the array is unchanged:

```javascript
let arr = ['a', 'b', 'c', 'd', 'e', 'f'];

<shape of arr> = {
    0: 'a', 1: 'b', 2: 'c',
    3: 'd', 4: 'e', 5: 'f',
    length: 6
}

delete arr[3];

<shape of arr> = {
    0: 'a', 1: 'b', 2: 'c',
    4: 'e', 5: 'f',
    length: 6
}
```

![](_meta/delete-array-element.png)

This makes perfect sense based on the way `delete` works, but it will be a lot of pain if someone has to debug array issues because you deleted an element from the array this way.

The right way to remove an element from an array is either to set it to `undefined` or use `Array.prototype.splice`:

```javascript
arr[3] = undefined;

<shape of arr> = {
    0: 'a', 1: 'b', 2: 'c',
    3: undefined, 4: 'e', 5: 'f',
    length: 6
}

arr.splice(3, 1);

<shape of arr> = {
    0: 'a', 1: 'b', 2: 'c',
    3: 'e', 4: 'f',
    length: 5
}
```

Beware the delete

# 02.09.2022 - JavaScript/Named Imports and Dead Code Elimination

One thing about JavaScript that is sometimes confusing: The **named imports**.

When there is a big module that exports a lot of things, we usually think that we can use named import to get just what we needed in that module, and the rest of the thing will magically disappear. It's not.

What really happens is, in _development_ mode, **everything still gets included** when we bundle the application. In _production_ mode, some bundlers will have the built-in dead code elimination (or tree-shaking) feature kick in to remove unused codes.

For example, let's create a mini project to illustrate this behavior better. We are going to have an `index.js` file for our entry point, and a `lib` folder containing some library files: `a.js`, `b.js` and `c.js`, and a `lib/index.js` file where we blanket export everything in our libs:

```
.
├── package.json
└── src
    ├── index.js
    └── lib
        ├── a.js
        ├── b.js
        ├── c.js
        └── index.js
```

First, let's export a couple of things in our libs:

```js
// lib/a.js
export const a = 10;

// lib/b.js
export const b = "Hello";

// lib/c.js
export const c = (name) => console.log(`HELLO, ${name}!`);
```

Re-export everything in `lib/index.js`:

```js
export * from './a';
export * from './b';
export * from './c';
```

And import just what we needed in `index.js`:

```js
import { b } from './lib';

console.log(b);
```

Now, we build the project in two different modes: development and production, and use `webpack-bundle-analyzer` to analyze the difference:

```json@focus=5:9
{
  "name": "webpack-test",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "build": "webpack build --profile --json > stats.json",
    "build:dev": "webpack build --mode development --profile --json > stats.json",
    "analyze": "webpack-bundle-analyzer stats.json"
  },
  "license": "MIT",
  "devDependencies": {
    "typescript": "^4.5.5",
    "webpack": "^5.68.0",
    "webpack-bundle-analyzer": "^4.5.0",
    "webpack-cli": "^4.9.2"
  }
}
```

In production build, as expected, there is only module `b.js` got imported, and Webpack went as far as inlined the exported values into the code:

```bash
$ yarn build && yarn analyze
```

![](_meta/webpack-dce-prod.png)

But in development mode, you will see that everything got bundled, even the unimported modules like `a.js` or `c.js`:

```bash
$ yarn build:dev && yarn analyze
```

![](_meta/webpack-dce-dev.png)

If we modify the `src/index.js` to import directly from module `b` instead of from the blanket re-exports in `lib/index.js`, you will get what you expected when building in development mode:

```js
import { b } from './lib/b';

console.log(b);
```

![](_meta/webpack-dce-dev-2.png)

OK, now we understand how named imports behave in different build modes. As long as we import things selectively, we are good in a production build, right?

Sadly it's not!

Not all libraries made the same, for example, the infamous `lodash` package. This library was architected in a different way (go explore it yourself, check the [lodash-cli](https://github.com/lodash-archive/lodash-cli/blob/master/bin/lodash) and [lodash](https://github.com/lodash/lodash) source code). Named imports won't work as you expected!

```bash
$ yarn add lodash
```

Try to import just the `pad` function in your `src/index.js`:

```js
import { pad } from 'lodash';

console.log(pad('abc', 8, '_'));
```

And build in production mode:

```bash
$ yarn build && yarn analyze
```

What you get is a whopping 531kB of lodash in your bundle, and that's not great:

![](_meta/lodash-bigass.png)

What if we selectively import just the `lodash/pad` file?

```js@focus=1
import { pad } from 'lodash/pad';

console.log(pad('abc', 8, '_'));
```

![](_meta/lodash-pad-tentacles.png)

The bundle size was reduced to 22.15kB, not bad, huh? But there are still a lot of extra dependencies that got bundled, and Webpack cannot concatenate them to the module.

What you can do is, instead of using `lodash`, just use `lodash-es` package, this is still the lodash but the build is split into modules.

```bash
$ yarn add lodash-es
```

We still need to specify the import path for each method we are using:

```js@focus=1
import { pad } from 'lodash-es/pad';

console.log(pad('abc', 8, '_'));
```

![](_meta/lodash-es.png)

But things get better! The total bundle size is now 1.33kB, a huge leap from 531kb!!!

Maybe I should rename this post's title to: "How I reduced 500% of the bundle size when using Lodash".

**What's next?**

- https://developers.google.com/web/fundamentals/performance/optimizing-javascript/tree-shaking
- https://developers.google.com/web/fundamentals/performance/webpack/decrease-frontend-size

Named imports and dead code elimination

# 02.04.2022 - JavaScript/Use any ASCII characters as a variable name

In JavaScript, you can use any ASCII characters as variable or function names, even non-English words or some special symbols:

```javascript
const π = 3.1415
console.log(π);

const Δt = start_time - end_time;
console.log(Δt);

const tên_tui = "Huy";
console.log(tên_tui);

const 五 = 5;
console.log(五 + 10);

function 합계(первый, второй) {
    return первый + второй;
}

console.log(합계(7, 8));
```

But sadly you cannot use emojis:

```javascript
const ⏰ = new Date();
//    ^^ Error: Invalid character
```

Apparently, this is not only possible in JavaScript but in almost every language.

Non-English Variables

# 01.17.2022 - JavaScript/Console Assert Command

The built-in `console` comes with the `console.assert` method, which is pretty useful to write some tests in your code.

This method has the syntax of:

```javascript
console.assert(assertion: bool, msg: string, obj1: any, obj2: any,...)
```

When the `assertion` expression returns `false`, the execution will be stopped, and the `msg` string will be printed out after the `"Assertion failed:"` message. You can format the `msg` just like how you format strings in languages like C++, using any `obj` followed after `msg`.

Otherwise, the execution continues.

For example:

```javascript
const actual = 10;
const expected = 15;
console.assert(actual === expected, "Expected %d. Got %d", expected, actual);
console.log("All good!);
```

Result:

```
Assertion failed: Expected 15. Got 10
```

If we change `actual = 15`, the output on the screen will be:

```
All good!
```

