I can’t figure out why in an @RemoteAction method you would want to JSON.serialize the object being returned? I see this in a lot of code and I’m trying to understand the reasoning. I thought @RemoteAction automatically serialized it for you. In fact when doing this it appears you must decode using htmlDecode since it’s double encoded, once by Javascript Remoting and again by JSON.serialize method.
I trying to understand from an application design perspective the benefit of doing JSON.serialize and returning a String versus just returning the object/class when using JavaScript Remoteing.
Why do this:
@RemoteAction
public static List<User> searchUsersByName(String searchText) {
return ChatterUIPeopleService.searchUsersByName(searchText);
}
Versus doing this:
@RemoteAction
public static String searchUsersByName(String searchText) {
return JSON.serialize(ChatterUIPeopleService.searchUsersByName(searchText));
}
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Since you’re not required to do this, I believe people just do it because they don’t know any better. They think “I’m calling this from Javascript, I better return JSON, so I need to serialize it.” It’s just one of many options that generate additional work, like returning String.valueOf(123) and sending it to a method that just does Integer.valueOf('123')
Method 2
If you’re just loading data inside of the page I would strongly recommend not to use JSON.serialize. Especially for data intensive operations the payload is much bigger. As I’m a big fan of JSRemoting let me shortly list the advantages:
- no attribute property, meaning no type and even better no url (reduced payload)
- no escape characters for nested json (reduced payload)
- doesn’t count against API calls (cool if you use remoting for HTTP-proxying)
- much json heap-size friendlier (yes the json.serializer has it’s own heap size limitation)
- real js date objects (easier to handle than iso date format!)
- increases robustness towards governor limits (remoting response can be handled!)
- and my personal favorite: referencing of recurring elements(!!), that means that e.g. sobjects in the json structure that occur more than once are only referenced in later occurences (check the actual transport JSON payload if you don’t believe me and watch out for “serId” and “serRefId” properties) This can save an incredible amount of text and it’s completely transparent for the developer as the references are resolved in the resulting js object.
Personally I think that JSRemoting is currently on of the most important and versatile features for the development of modern web applications on the force.com platform.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0