3 ms·

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

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 more expressive type system would allow more accurate type information. If you have concrete suggestions for improving the TypeScript definition file, please please hop over to github.com/facebook/immutable-js/issues and write them up.

skrebbel 12y ago
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. I have spent weeks trying to use it well with TypeScript, and then dropped it and going for vanilla JavaScript instead. I haven't looked back :-) I'll see if I can dig up any of the stuff I did to make it work better with TypeScript, but I don't think I could find many substantial improvements to the .d.ts only. What I ended up making was wrappers for some stuff that had more cumbersome syntax, but as a result did allow for more type checking. About the records, I believe that I might have a couple of ideas. I'll start an issue on github to discuss it.
- 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 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.

skrebbel 12y ago

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. I have spent weeks trying to use it well with TypeScript, and then dropped it and going for vanilla JavaScript instead. I haven't looked back :-) I'll see if I can dig up any of the stuff I did to make it work better with TypeScript, but I don't think I could find many substantial improvements to the .d.ts only. What I ended up making was wrappers for some stuff that had more cumbersome syntax, but as a result did allow for more type checking. About the records, I believe that I might have a couple of ideas. I'll start an issue on github to discuss it.

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 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.