How to make ajax calls in Polymer.js
As I’m starting new to the concept of web components and polymer.js during development I came across a lot of mental barriers as I try to develop my application with polymer.js as I would with other “classical” frameworks. I won’t do a step-by-step guide on how to use it, see.
Note: Please keep in mind that this article is currently for Polymer 1.x API and Polymer 2.x (and even Polymer 3) are released. As this article has a lot of referrals from Google I wanted to point this out to new visitors
What is Polymer.js?
The Polymer library is designed to make it easier and faster for developers to create great, reusable components for the modern web.
At first it looks like a promising approaching for developing reusable components which are easier to maintain and to use.
Making Ajax calls
Making basic ajax calls and saving them to an object is quite simple and easy-going:
The iron-ajax component offers a lot of properties. You are able to add some params, successCallback, debounce for the auto Call function etc. (see). During the development of a small web application I wanted to create different dynamic URL Endpoints and initiate the calls programmatically. For this purpose the documentation only says that the iron-request component should be used:
iron-request can be used to perform XMLHttpRequests.
Using iron-request for complex calls
Starting from the one-line comment that developers can use iron-request to perform XHR I implied that iron-request can be used like any other abstraction layer from other frameworks (e.g. $.ajax) but I was highly wrong! But let’s start with the scenario:
- A user types some Number into an input field and based on that Number I will create the endpoint (it’s a REST API) dynamically.
- Based on the endpoint I will start an XHR and show the user a formatted result.
The problem is that the iron-request component doesn’t allow this!😮 You’re not allowed to use different URL’s to make http requests to different endpoints. This means if you perform an request to a REST API you’re not able to change the URL afterwards, it is like a final XHR call.
To understand the issue here, I created a plunkr with sample code:
To be sure that I’m not doing something wrong, I’ve looked into the source code of iron-ajax as it relies on the iron-request component. The iron-ajax component is handling URL updates by managing a list of iron-request elements and after request is finished it is removing the iron-request element. This also means that for each new iron-ajax call a new iron-request element is created in the DOM (shadow DOM).
As I still want to use a polymer XHR component to do multiple ajax calls with different Endpoints, I changed the way of developing it.
Solution for doing different ajax calls
As I’m still not sure if the iron-request component should have this behaviour, doing multiple ajax calls with polymer.js is possible with the iron-ajax component:
- Create a iron-ajax component
- Set the “auto” property , use the “on-response” Handler to add a callback function to it
- the url property should be a property of your component
Each time you want to make a new HTTP Call you have to do the following:
- Update the url for which your iron-ajax component has a binding
- handle the response in your Response Handler (the response Handler is returning an iron-request object, so you access your properties via response.detail.response.<property>)
- Update your properties based on the response (using this.set(..) is needed to tell notify the binded component)
At the end if you want to do ajax-calls there are two ways of doing it:
- Use iron-ajax with the little overhead that you only have on response Handler. You shouldn’t do complex things here, as the Handler could get ‘fat’ and is more delegating things instead of just updating properties.
- Write your own polymer-ajax component based on iron-request. For complex cases, this will be the go-to way but you should look into iron-ajax and how the polymer guys managed the static behavior of iron-request.
- After working a lot more with iron-ajax and following some discussion it looks like developers should be generally careful of using iron-ajax. If you have different endpoints you should use multiple iron-ajax objects instead of one “fat” iron-ajax element.