I’ve been using the Xano Connector for some time, but am having some really frustrating issues with the dreaded “undefined is not iterable” issue, but in a strange context. I am using pagination on many of my APIs due to the sheer volume of data, and this seems to have completely broken the connector, since the return data type is not in an array (it is just a single object, with the nested “items” array containing the actual data).
The connector however seems to not have support for this, despite having the native fields for all the various pagination features, suggesting at some time it was working properly.
Currently my only workaround is to add “safe array” to the Xano API to return the entire API back as a single-item array, which seems to solve the issue - but this is messy from a bubble perspective, since now everything needs a “:first item” reference to access it.
This seems like a bug, perhaps introduced by a change at the bubble backend - since there really should be no reason every API should return an array even for a single result, and this is very much not best practice from an API development nor maintainability perspective.
Any chance you can take a look into it? As mentioned it’s pretty easy to replicate - use an API with paging enabled, set up the result data, watch it error out.
For those who stumbled on this thread whilst trying to troubleshoot this frustrating and convoluted issue, I thought I’d provide an update (TLDR - it is easily solved by checking a few basics).
The Xano Data element expects a LIST of data in the response. Your API should therefore provide its response as a list. This is important, even if your API returns just a single item. You can include the function “safe array” in your API to ensure this. Alternatively, use “Xano Get” for single-item API responses.
If you have Xano pagination enabled, be sure to ONLY include the content within the “items” key (which should be an array of objects returned from your data queries) in the API connector response configuration. This was the issue I had.
Don’t manipulate the response output with pagination enabled with “safe array”. This results in the top-level response (Xano Pagination metadata, if enabled) to be nested in an array, with the “items” also being an array. This was the second part of the issue I had, since I enabled pagination long after first building the API doh!.
Do NOT under any circumstances return an array with a null inside it (i.e. [null]). This will cause no end to troubles for you, as bubble really REALLY does not like this. You will need to be extremely cautious in your API functions, taking special care with evals and addons and other arrays. This is an ongoing battle for me, and I simply post-process all my data prior to the response, using coalescing NULL to replace any blank arrays with “[ ]” (i.e. an empty array). You can achieve the same result by using “get” with a default of “[ ]”.
The final issue you may run into is if you have misconfigured your response, particularly where a nested object might exist or bubble misinterpreted the data type. Of particular issue is “ID” in a nested object, which bubble for whatever reason often interprets as a text field. It will absolutely error out if you set a numeric field as text. This is often an issue for me when developing APIs and changing structures etc. to test with bubble.
If you include any image data in your requests that depends on the bubble database, you might need to do a search/replace for a missing https. This is because bubble has their own CDN, so referencing the URL in some circumstances will not need HTTPS to function on bubble, but will cause issues if uploading that image to Xano (e.g. via a Picture Uploader element).
As an aside, with pagination be VERY careful about how you request page changes. If you dynamically link the pagination data into the request parameters, consider the scenario of the user being on page 2, then decides to search for something. If you are using real-time search (e.g. no search button), the moment the user finishes entering the search term, the request is sent with “2” as the requested page. If however the search only resulted in a single item, you will get a blank result, since there is no page 2 in the return data but Xano won’t throw an error. You will need to refresh data a second time with the page number set back to 1, or use a search button and a JSON plugin to build the request parameters. I’d use JSON manipulator for this task, as opposed to multiple states set via workflow action - this is how I did it initially until I made my own version of this plugin.
In my case, I forked the plugin and add a new feature in to track pagination vs. field-change events, plus many other features, as my needs are quite far beyond what was possible with the standard plugin. I may release that one day, but only once my app is launched and I have battle-tested and documented it fully to ensure robustness, since it effectively replaces the need for the bubble database backend and authentication functionality - a VERY difficult task!
