leebyron

7 ms·

31.
by leebyron 12y ago
Yes, please open a github issue about this. There are some non trivial changes needed to make this possible, but this is something I would love to enable in a future version. Also, if you're minifying and gzipping your static resources
32.
by leebyron 12y ago
There should not be linearly increasing memory usage. If you find memory leaks like this, please file bugs on github issues. AFAIK there currently aren't any. Of course, if you do something like keep an undo stack around (check out swa
33.
by leebyron 12y ago
Thanks for chiming in on github! 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
34.
by leebyron 12y ago
Great feature. Immutable.js supports something similar but at the access site: var m: Im.Map<string, Im.Set<string>> = Im.Map(); console.log(m.get('foo')); // maybe undefined console.log(m.get(&
35.
by leebyron 12y ago
Slice is done in O(logN) with very little copying. This works via structural sharing with the original List.
36.
by leebyron 12y ago
I think there are two concepts being confused here - this is not the same as `var` vs. `const`/`let`. Immutable.js implements persistent data structures, which are entirely runtime concepts. --- Deep copying isn't very common beca
37.
by leebyron 12y ago
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
38.
by leebyron 12y ago
Of course there's no way to know in O(1) time if you've done two edits that just so happen to sum to no-op, regardless of if you're using Immutable.js or not. However, depending on how to implement undo, you might be in good
39.
by leebyron 12y ago
Performance: comparable Data-structure techniques: nearly the same API: do you like point-free functions (mori) or methods (immutable.js) mori is a direct compile of clojurescript's excellent data structures and functional tools (writt
40.
by leebyron 12y ago
Not nefarious, but definitely something to keep in mind if you recruit via github committer lists :) I accept any reasonable pull request, even if it's a spelling fix. There have been some great bug fix pulls as well.
41.
by leebyron 12y ago
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 deci
42.
by leebyron 12y ago
That is true! In fact, an earlier version of this library was called "persistent-js", and I know this is a pretty subtle distinction - I found it easier to talk to people about when I talked about it via immutability and so I ende
43.
by leebyron 12y ago
Personally, a good amount! I know a lot of the React team are also big fans of Om. React has always been inspired by functional programming and I think in another universe we would have preferred to write it in Scala or Haskell or Clojure.
44.
by leebyron 12y ago
It would help if I could spell. Fixed the typo and: http://en.m.wikipedia.org/wiki/Hash_array_mapped_trie
45.
by leebyron 12y ago
The feature set is comparable sans yet to come SortedSet and SortedMap (aka Red Black Tree). Performance should also be comparable if not slightly faster than mori in some iteration cases, as it's tuned for JS instead of ClojureScript
46.
by leebyron 12y ago
I actually started by writing it in TS and later moved to just a TS declaration file and a raw JS source. This means it can be used smoothly in both environments (similar to using a definitelytyped resource).
47.
by leebyron 12y ago
Hey, I'm the author of this library. It's definitely inspired by mori (and clojure and Haskell) and the reason I ended up building something different was to present a more JavaScript friendly API (and academically, to learn about