Skip to main content

Bug Tracker

Side navigation

#5947 closed feature (wontfix)

Opened January 26, 2010 08:54PM UTC

Closed October 25, 2010 12:15AM UTC

Last modified March 14, 2012 12:44AM UTC

Add JSON.encode capability

Reported by: iros Owned by:
Priority: low Milestone: 1.4.2
Component: ajax Version: 1.4.1
Keywords: json Cc:
Blocked by: Blocking:
Description

$.parseJSON converts a string -> object

it would be very helpful to have a:

$.encodeJSON which would convert an object -> string.

think it would be more correct to return an array of on/off states: ["on", "off"] etc.

Attachments (0)
Change History (9)

Changed June 14, 2010 12:42AM UTC by dmethvin comment:1

component: unfiledajax

Changed October 25, 2010 12:15AM UTC by rwaldron comment:2

description: $.parseJSON converts a string -> object \ \ it would be very helpful to have a: \ $.encodeJSON which would convert an object -> string. \ \ $.parseJSON converts a string -> object \ \ it would be very helpful to have a: \ $.encodeJSON which would convert an object -> string. \ \ think it would be more correct to return an array of on/off states: ["on", "off"] etc.
priority: majorlow
resolution: → wontfix
status: newclosed

use JSON.stringify() natively or with json2.js

Changed November 23, 2010 12:13AM UTC by snover comment:3

#7599 is a duplicate of this ticket.

Changed November 25, 2010 06:37PM UTC by anonymous comment:4

Stupid question: why? Adding a jQuery alias to JSON.stringify would take 2 minutes and 3 lines of code, and it would save tons of developers who are ignorant of JSON.stringify a bunch of time. Plus, you already have a JSON parser (despite the existence of the built-in eval), so it seems like a no-brainer to have a companion method.

Changed November 25, 2010 07:35PM UTC by snover comment:5

1. Not all browsers have a native JSON object. The size of a non-native implementation is not trivial.

2. There is no point to just alias a normal browser function. This is like saying we should have a jQuery.math alias to the Math object because some people don’t want to use it directly.

Changed November 26, 2010 05:39AM UTC by anonymous comment:6

The Math object is part of the JS language; if you get the O'Reilly pocket reference, or look at W3Schools, or check any other JS reference, it will include Math. This is not true for the JSON object; it's more like (for instance) the map function because, as you pointed out, JSON doesn't exist for all browsers (but jQuery DOES include a map implementation). And isn't the whole idea (or at least one of the core ideas) of jQuery to eliminate cross-browser issues? The map function is certainly not the only feature jQuery implements to make up for a lack of browser implementation (mouseenter, mouseleave, and the onready events are some other examples, and I'm sure there are more).

Changed November 26, 2010 07:27AM UTC by ajpiano comment:7

The goal of jQuery is not to "eliminate cross-browser issues" by providing a safe alias for every single thing someone could ever possibly want to do.

jQuery regular parses JSON as part of dealing with AJAX responses, as well as parsing JSON-encoded data from data attributes. jQuery *never* needs to stringify objects internally

"Adding a jQuery alias to JSON.stringify would take 2 minutes and 3 lines of code"

Except for the part where you have to write an entire JSON serializer for places where native JSON doesn't exist.

"and it would save tons of developers who are ignorant of JSON.stringify a bunch of time."

If someone comes into the jQuery support channel and does not know how to serialize to JSON, we direct them to JSON.stringify. A lot of jQuery developers are ignorant of a lot of parts of JavaScript, it is not jQuery's purpose to provide them with a magic, comfy jQuery wrapper in order to familiarise them with those aspects.

Many people start off with jQuery wondering, for instance, what the "jQuery equivalent" of parseInt is. There isn't one. You just use the browser's native parseInt method. The best practise in JS circles for sometime has been to use native JSON, and include Douglas Crockford's json2.js, which provides a fallback in the event there is no JSON object (which is only ie7 and below). I do believe this should continue to be the case.

Changed November 26, 2010 08:31PM UTC by anonymous comment:8

Ok, but map *IS* a core part of JS (as of v1.6; https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/map). It's even more core than the JSON module, in the sense that it's part of the JS spec (vs. JSON, which you won't find here https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects).

So, you've got a map function, which exists built-in in some browsers and not in others. Because it's a useful thing to have, jQuery provides an implementation of it (presumably that implementation is just an alias to the real map function on browsers with map support? I haven't actually checked the source). Same thing for those events I mentioned (mouseenter/mouseleave/ondomready).

Then you've got JSON.stringify, which ... exists built-in in some browsers and not in others, and is a useful thing to have, but ... jQuery doesn't provide an implementation of it. What I'm not understanding is, what criteria are you using to decide that useful things A/B/C/D which only some browsers implement DOES go in to jQuery, but useful thing E that only some browsers implement doesn't? Is there (for instance) a 50 line cut-off for features implemented in some browsers, and the mouseenter implementation only take 50 lines, but JSON.stringify takes 51?

Changed November 26, 2010 09:43PM UTC by ajpiano comment:9

"(presumably that implementation is just an alias to the real map function on browsers with map support? I haven't actually checked the source)."

There's an old adage about assuming that applies just as well to presuming in this case. jQuery.map *does not* fall back to Array.prototype.map (indeed, many people's complaint about it is that it is not consistent with the Array.prototype.map spec), but is a custom implementation.

Again, jQuery uses .map internally in a number of places (both the $.fn.map (which falls back to $.map) and $.map itself) , which it never does for JSON.stringify. jQuery constantly is working with arrays of elements and using those arrays to generate other arrays.

FURTHERMORE, people *constantly* complain about the fact that jQuery's size is growing over time, AND that jQuery has code in it only for IE. Providing a JSON.stringify fallback would ONLY be used for IE, and would add considerable bloat (3.5% of the entire library size).

FURTHER-ERMORE, jQuery is a DOM/events/AJAX library. Standardising events across browsers is pretty much its bread and butter. "jQuery does a document ready handler , therefore it should provide a JSON stringifier" is a rationale that does not hold much water.

(FYI: There is no hard-and-fast rule in terms of LOC count per feature.)