Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question: migration guide from Immutable.js for Map #112

Closed
vladp opened this issue Dec 4, 2019 · 3 comments
Closed

question: migration guide from Immutable.js for Map #112

vladp opened this issue Dec 4, 2019 · 3 comments

Comments

@vladp
Copy link

vladp commented Dec 4, 2019

Hello, since immutable.js does not appear to be maintained.
immutable-js/immutable-js#1689
we wanted to migrate to something else.

We just use Map's .get .set .delete .map .filter in web and react native apps.
With that light use, it is hard to justify 58kb minimized file size that immutable js brings
(they were thinking of making imports splittable in the 2015 roadmap, and this is when we started using that library, but that did not materialize )

With unmutable's map replacement (that I show below), our bundle size shows 9.8 kb minimized for unmutable (so we are saving about 50kb , based on our usage pattern)

I looked at the documentation for unmutable ( https://unmutable.blueflag.codes/api )
It seems that there are no 'replacement classes' so to to speak for immutable.

Is that undestanding correct? (I can see that it is possible to compose functionality from individual functions available in unmutable)

thank you

ps. this is how we are thinking of doing it at the moment (and then add types later...)

import get from 'unmutable/get';
import map from 'unmutable/map';
import filter from 'unmutable/filter';
import set from 'unmutable/set';
import deleteF from 'unmutable/delete';
import forEach from 'unmutable/forEach';

export class CommnIMap {
  constructor (data) {
    this._dataO= (data!=null)? data : {};
  }

  get (key) {
    return get(key)(this._dataO);
  }

  set (key, val) {
    return new CommnIMap(set(key, val)(this._dataO));
  }

  delete (key) {
    return new CommnIMap (deleteF(key)(this._dataO));
  }

  // map(mapper: (value: any, key: string|number, original: any) => newValue) => 
  map (mapperFn) {
    return new CommnIMap( map(mapperFn)(this._dataO));
  }

  filter ( fnValKey) {
    return new CommnIMap( filter(fnValKey)(this._dataO) );
  }

  forEach (fnValKey) {
    forEach(fnValKey)(this._dataO);
  }
}
@vladp vladp changed the title question: migration guide from Immutable.js for Map, Seq, List question: migration guide from Immutable.js for Map Dec 4, 2019
@dxinteractive
Copy link
Collaborator

Oh hi, sorry for not replying sooner. You're the first person outside of our organisation that I know of that has used this library. Yes, unmutable does not use its own classes, instead it's designed to operate directly on objects and arrays, which is one of the reasons that its so code-splittable.

What you have there looks good if you want to continue to use a class, it looks like that'll work nicely as a drop in replacement to continue to use code originally written for Immutable.js.

@vladp
Copy link
Author

vladp commented Jan 24, 2020

Hi, thank you for the reply, and for making this library available.

Yes, I have put it in production last months and it has been working well.
The size of the overall site is smaller now, thanks to your library and the hashmap works as a holder of state in react components, and in few other places where hashmap is used (they normally do not have more than 100 entries, so this is not taxing it much :-) ).

@dxinteractive
Copy link
Collaborator

Glad to hear it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants