Introduction

The JS Error: [object Object] is common on Magento sites.

This error is traced to a function called getFromServer which is a standard Magento function that retrieves user data from the server in multiple places.

In its default implementation, this getFromServer function throws a vague [object Object] function when it encounters any error from the server. This provides no information about which error occurred or what caused the error, which isn’t very helpful for debugging or investigating the issue.

Fortunately, we have a quick, straightforward fix that reveals the nature of the error and enables you to further investigate or action a fix.

Issue Discovery

The getFromServer function is part of Magento’s implementation for loading and managing user data. You can read more about this function in Magento's StackExchange post on Customer Sections.

There are multiple variations of this getFromServer function depending on the file and context, but it usually looks like this example from the customer-data.js file:

getFromServer: function(sectionNames) {
var parameters = {
    'requesting_page_url': window.location.href
};

if (productId) {
    parameters.data = {
        'product_id': productId
    };
}

if (_.isArray(sectionNames)) {
    parameters.sections = sectionNames.join(',');
}

return $.getJSON(options.sectionLoadUrl, parameters).fail(function(jqXHR) {
    throw new Error(jqXHR);
	});
}

You may see other versions of getFromServer that include extra parameters such as forceNewSectionsTimestamp and different function bodies, but in this article we will consider them together.

The final few lines of the function–which should be identical across the getFromServer implementations–request user section data from the server:

return $.getJSON(options.sectionLoadUrl, parameters).fail(function(jqXHR) {
    throw new Error(jqXHR);
	});

If an errors occur and the server cannot respond with the requested data, the error handler is triggered and the server error response, jqXHR, is thrown as an error.

The problem is that jqXHR is a JSON object, and the JavaScript error parameter expects a string. As a result,  the error converts the jqXHR object directly into its string form [object Object], which makes the object itself into a sort of “black box” that hides any helpful error information.

Potential Solutions

There are multiple methods to reveal the error object, depending on how you'd like to display the error data.

The most straightforward way is to simply stringify the entire JSON object, as below:

return $.getJSON(options.sectionLoadUrl, parameters).fail(function(jqXHR) {
    throw new Error(JSON.stringify(jqXHR));
	});

This reveals the error object from the server in a form you can observe in the browser console and in Noibu, albeit in a relatively raw format.

If you only want to see specific attributes of the jqXHR error object, you can throw a more specific error with only those attributes–e.g. statusText. You could also add code to clean up the response or format it to be more readable.

For example:

return $.getJSON(options.sectionLoadUrl, parameters).fail(function(jqXHR) {
		const errorMessage = jqXHR.statusText
    throw new Error(formatNicely(errorMessage));
	});

Next Steps

Once the JSON object is stringified, you should see the previous object Object error no longer actively occurring:

Instead, you'll begin seeing individual errors with the actual stringified JSON error object begin to appear. To easily search for all of these errors, you may search by{or {readyState as this is the standard format of the JSON error object returned from the Magento server. 

One of the most common errors you'll see appear once this fix has been applied will be the somewhat cryptic {readyState:0,status:0,statusText: error} error. This is almost always triggered by HTTP 0 errors occurring on requests to the Magento server. Read our article here for more details.

Conclusion

Applying this fix will NOT solve the underlying error that causes getFromServer to fail. Instead, this fix uncovers the error information for investigation and debugging. Without this additional context, you may find it difficult to troubleshoot or further investigate the real problem, as [object Object] will always be the same regardless of the error's specifics.