immutable-js: .fromJS doesn't preserve key types

Sorry to open this thing up again, but I’m working in a very large codebase where a migration from Integers -> Strings could potentially be very painful. Is there a way to extend a Map to a StringMap? Something like:

import { Map } from 'immutable';

export class StringMap extends Map {
    get(key) {
        key = key.toString();

        return super.get(key);
    }

    set(key, val) {
        key = key.toString();

        return super.set(key, val);
    }
}

Any advice on how to approach that? Edge cases I should be aware of?

I kinda realized after making this I should just make the Map a List, but here is a fromJS fn that will recursively make all the number like keys of an object integers.

import { isNaN } from 'lodash'
import { fromJS, Map } from 'immutable'

const integerizeKeys = stringMap => stringMap.reduce(
	(results, value, key) => {
		const integerizedKey = parseInt(key, 10)
		const fixedKey = isNaN(integerizedKey) ? key : integerizedKey
		return results.set(
			fixedKey,
			Map.isMap(value) ? integerizeKeys(value) : value
		)
	}, Map()
)

export default function (obj) {
	const immutableObj = fromJS(obj)
	return integerizeKeys(immutableObj)
}

This is actually just JavaScript doing it’s thing. JavaScript Object keys are always strings.

var obj = {42: "test"};
// get the keys using Object.keys()
var keys = Object.keys(obj).forEach(function (key) {
  console.log(key, typeof key);
});
// get the keys using for in
for (var key in obj) {
  console.log(key, typeof key);
}

@Altiano It’s not a quirk of immutable.js, it’s a “quirk” of JavaScript.

Object keys are property names. Property names are always strings (or symbols, but that’s probably not as important). If you use non-string property names when defining properties, the names will be converted to strings. Don’t take this as a snark but I strongly recommend you solidify your understanding of the language before moving on.

I strongly recommend the You Don’t Know JS series of books by getify because they’re available online for free and are pretty exhaustive without dwelling too much on the author’s personal opinions. If you can’t set aside the time to read them from back to back (which is understandable) just use them as a “take what you need” reference and look up the parts of JS you find confusing.

FWIW if you want to observe the behaviour more directly, open your browser’s console (F12 or Ctrl+Shift+J/Cmd+Shift+J depending on your platform) and compare the following (assuming Chrome/Edge or a recent version of Firefox):

var obj = {1: 'a', 2: 'b', 3: 'c'};
var map = new Map();
map.set(1, 'a');
map.set(2, 'b');
map.set(3, 'c');

Array.from(map);

Object.entries(obj);

The last two lines show you what native maps and objects look like when converted to arrays of key-value pairs. While as you can see it is possible to treat objects like maps, the keys are always strings. There are also some other caveats that make objects unfit as substitutes for proper maps (whether native or immutable.js).

(Another limitation is that some object property names are “special” and may have unintended side-effects, so it’s a bad idea to use objects as maps when dealing with potentially malicious or uncontrolled values for keys.)

@Altiano read the original discussion again:

• when creating maps from objects, keys are always converted to strings because object property names are already strings

• when creating maps from arrays of key-value pairs, the keys’ types are preserved

This is the exact behaviour you’re seeing: the keys aren’t converted by immutable. The original discussion was the result of a confusion about JavaScript’s behaviour (i.e. object keys always being strings), not something immutable does.

Thank you for a great discussion. I learned a lot. I see that the issue is closed, but I’d like to add some points for others to find.

As @leebyron says, consistency is good, i.e. use string-id OR integer-id. If you like me use Immutable with Redux and your data originally comes from a database, you might have integers as both primary and foreign keys. If you need to do lookups in your Redux store by foreign key you’ll be best off to use integers as keys in your Immutable.Map. This way you never need to “manually coerce” to string when performing lookups.

Here is how I load data into Redux from my API in order to preserve the keys as integers. Part of the reducer:

case DRAWING_RECEIVE:
  let updatedDrawings = Map(
    action.payload.drawings.map(item => {
      return [item.id, fromJS(item)];
    })
  );  
return = state.update('items', items => items.merge(updatedDrawings));

N.b. I have an “items” Map for storing the actual data in each slice in the store, hence “items” in the code above. It took me some reading and testing before landing in this key-solution. It really works well and I recommend it.