Typescript support

[eyalw]

I'd love to see typescript support or at least type declaration file.

thanks!

[eyalw]

This is the only drawback I have from using it + the number of download/months in npm. but I hope that will change with growing popularity

[dmaccormack]

Good suggestion, thanks!

[darcyparker]

I just evaluated a number of similar libraries (including JSONCrush, lz-string's compressToEncodedURIComponent()) and this library had both the best compression and best readability for my data.

I am mentioning lz-string because it wasn't in https://www.jsonurl.org/#relatedwork, and it seems to be very popular according to npm. Of course lz-string is not readable... but I was surprised that it didn't do nearly as well as this library for my data. It makes sense in retrospect though... because lz-string is more general purpose and is probably better for larger data sizes than my use cases.

So I am choosing this library.... I also needed the typescript defs too.. so just added #165.

[dmaccormack]

I just evaluated a number of similar libraries (including JSONCrush, lz-string's compressToEncodedURIComponent()) and this library had both the best compression and best readability for my data.

Wow, that's a pleasant surprise. Thanks for the info! What sorts of input did you try it with?

I am mentioning lz-string because it wasn't in https://www.jsonurl.org/#relatedwork, and it seems to be very popular according to npm. Of course lz-string is not readable... but I was surprised that it didn't do nearly as well as this library for my data. It makes sense in retrospect though... because lz-string is more general purpose and is probably better for larger data sizes than my use cases.

Thanks for the heads up. I'll take a look at lz-string and add a paragraph to related work section.

[darcyparker]

Yes - it was nice to see. In my case, the JSON I am compressing has short key/values (1 char each). And I am using chars that don't need escaping. So this helps json-url.

I believe lz-string is using base64 encoding of the lz compressed result. It just uses a different character set https://github.com/pieroxy/lz-string/blob/master/libs/lz-string.js#L14-L15. If I am correct, then it makes sense it doesn't do as well because of the overhead of base64. Perhaps with larger input sizes it can overcome this overhead.

JSONCrush had better compression than lz-string too... but not as good as json-url.

Some example inputs I used:

[{"n":8,"i":6},{"n":7,"i":7}]
[{"n":10,"i":1},{"n":2,"i":2},{"n":3,"i":3},{"n":4,"i":4,"s":0},{"n":5,"i":5,"w":21},{"n":6,"i":6,"w":30},{"n":7,"i":8},{"n":9,"i":9}]

I am only listing a couple of examples... In these examples there are definitely patterns with i and n. But this is not always the case. The important thing is that for different types of JSON input, the results of which library is the best at compression varies.

json-url will do well if the developer experiments with different schemas/interfaces for their JSON object. Whereas, if the payload is large and/or is arbitrary (not just some JSON), then maybe lz-string is the best choice.

The bonus, is that I think you did well aesthetically with choosing how to re-encode the JSON for the URL. Your choices make the result easy for a human to read. This is valuable to me... and a nice bonus when it beats other libraries in terms of size.