71–80 of 86 posts
Is it possible to use this as a drop-in replacement for Angular POJOs that hold $scope data? We're hitting a whole class of bugs which are basically due to mutability of native JS objects, and we could use something like this for the most complex ng-controllers.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
For example, let's say we have a mercury app [0], and the state of the app is based on a persistent immutable data type. It would seem to mean that so long as the state of the app doesn't change much that everything would work just fine because there total number of diffs is minimal. However, what happens in the case of an app where there are event sources that produce lots of data (mouse movements for example) and therefore can result in lots of diffs. Wouldn't this be a source of memory usage that just keeps creeping up and for which memory is never released?
I have started using this with our React.js project and have been able to squeeze out efficient DOM updates comparable to Om. For fun I also made a library that overloads Immutable.js and JSON operations (and can do the same for mori): https://github.com/zbyte64/dunderdash
Doesn't React already do efficient DOM updates for you with their virtual DOM and it's diffing mechanism? Or are you referring to something else?
I have started using this with our React.js project and have been able to squeeze out efficient DOM updates comparable to Om. For fun I also made a library that overloads Immutable.js and JSON operations (and can do the same for mori): https://github.com/zbyte64/dunderdash
Doesn't React already do efficient DOM updates for you with their virtual DOM and it's diffing mechanism? Or are you referring to something else?
Earlier quoted context omitted.
But it's not the same API. There is a clear and plain specification on what each of those operations do, and the methods on these objects do not do them. I get what you're thinking about re-using what the programmer already knows but this only poisons the well by adding confusion to their existing knowledge. "Push adds a value to a list, oh wait, except it depends what type of list". It is much easier to remember tha…
I think there are two opposing forces: the first, as you say, pushes us away from re-using the same names, because that can cause confusion; the second, however, pushes us to re-use existing knowledge through metaphor. This second force is ubiquitous in natural language, but common also in programming language where operators like "+" and "[]" are re-used in different contexts without practical ambiguity, and with th…
Earlier quoted context omitted.
This is great feedback and a decision that I didn't take lightly. I ultimately decided that the mental cost of remembering a new API would outweigh the potential for accidental return value mis-management. It's hard to make a decision like this sans-data, so I had to make a gut call. I'm really interested to hear feedback of issues encountered in-practice due to this. Of course, if I'm wrong about this (and there's a…
You've clearly put a massive amount of work into this API, which I applaud. One trick I use in FSet that you might want to copy is default values for maps. This is particularly handy when the range type of the map is another collection: you can make the default value be the appropriate kind of empty collection, making it unnecessary for code that accesses the map to check for a null value. In Java, for example: FMap…
Immutable.js supports something similar but at the access site:
var m: Im.Map> = Im.Map();
console.log(m.get('foo')); // maybe undefined
console.log(m.get('foo', Im.Set())); // never undefined
Earlier quoted context omitted.
I'm not happy with the Records impl yet. This is great feedback and resonates with some things I've already been thinking about. I'm especially not happy about how Records play with Typescript at the moment. Also, please keep feedback coming about Typescript. I'm sorry you feel it's half-assed, I'm trying to make the best of what Typescript gives me. You might notice that the .d.ts file is full of comments where a mo…
Hi! Just to be absolutely clear, I think that it's completely TypeScript's fault that Immutable.js's TypeScript support is half-assed - you could rather say that TypeScript's support for immutable well-typed data structures is half-assed. My only complaint about your work in that entire story is that the site somewhat implies that it works great in TypeScript, whereas my personal experience is kind of that it doesn't…
By the way, I had the same reaction to TypeScript. The internals of Immutable.js were originally implemented in TypeScript, but being forced to work with a subset of JavaScript with an imperfect type system was limiting and I eventually ended up with the codebase you see today of a .d.ts to describe public API type information and a vanilla JS implementation.
Good feedback about the story of how it works with TypeScript is a little over-sold right now. The reality is that it doesn't not work with TypeScript and one step better, the API source of truth is defined in TypeScript (and soon human readable html, I promise!)
Facebook's Flow typechecker is nearing a level of completion where we can open source it, and has a similar mechanism of .d.flow files. At that point I'll start maintaining both Flow and TypeScript definition files. Flow is currently more expressive than TypeScript but still doesn't solve all the problems you've outlined.
Both projects are really new, and one of Immutable.js's goals is to challenge the limits of the JS infrastructure we build with, including but not limited to the type-checkers.
What are the implications on memory usage in a long running app with something like immutable.js? For example, let's say we have a mercury app [0], and the state of the app is based on a persistent immutable data type. It would seem to mean that so long as the state of the app doesn't change much that everything would work just fine because there total number of diffs is minimal. However, what happens in the case of…
Of course, if you do something like keep an undo stack around (check out swannodette's blog for a great example of this) then of course you have linearly increasing memory usage. One great property of persistent data structures is that the memory usage will be much smaller than if you kept your undo stack as copied JS values because of structural sharing (see one of swannodette's recent talks for a great explanation of this).
In practice, if you're implementing an undo stack, you should remain conscious of memory usage. You may want to only keep a fixed maximum number of previous states around so you don't have linearly increasing memory use.
Hi! We would dearly love to use this in our code (a MEGA webclient subproject) but it's 51KB! Do you have ways to build only parts of this so that I can include (e.g.) only Immutable.Set? At the moment I'm using a custom immutable wrapper around a ES6 Set polyfill.
Also, if you're minifying and gzipping your static resources (standard practice these days), then Immutable.js is a relatively fit 15KB. For comparison, lodash is 8KB and jQuery is 30KB.
I definitely understand the desire to not include code that will never run (we pain to optimize this at FB), but at least it won't break the proverbial bandwidth bank.
Is it possible to use this as a drop-in replacement for Angular POJOs that hold $scope data? We're hitting a whole class of bugs which are basically due to mutability of native JS objects, and we could use something like this for the most complex ng-controllers.
If you get this working, and want to write a blog post about it, let me know!