Xano quality of life suggestions

aemondis

Hi, I have been in extensive development time for some time now (moving away from bubble following their disastrous pricing changes), but there's a few things I'd love to see as improvements in Xano. I don't want to clutter the forum with multiple requests, so thought I'd summarise here with my "wishlist". Already I'm loving Xano in almost every way (it's WAY more capable than anything in the bubble backend!) - but there's room to improve:

1. If I change something in a block, and don't save - ask me to confirm if I want to save! Please, please, PLEASE add this - you have no idea how frustrating it is to go through an update a block, get distracted, and click on something else - only to lose EVERYTHING I just did! This is easily the #1 gripe I have with Xano, as it has caught me up countless times and wasted hours of my time, only to realise "I must have forgotten to click save again".
2. In the debugger, if a block or conditional etc. has a description - use that in the debugger to describe the step. It's a nightmare having to follow through thinking "Get Record, Get Record, Edit Record" etc., when I have clear descriptions already on those blocks.
3. For the "Get Record" and "Has Record" - have the option for a case insensitive search. I am forced almost universally to use "Get All Records" with conditions for something as simple as doing a case insensitive search, or use an additional variable as a reference (not sure which causes more overhead?). Truth be told - I'd like to see "case insensitive" as an option for ANY conditional check in Xano, since 99% of the time I don't trust the case sensitivity of the input and don't want duplicates being created that are simply a different character case. As such, I very rarely use the lightweight "Get Record" due to this. No doubts, Xano could free up some overheads from the server infrastructure through simply this - since I am almost certain MANY of us do the same thing, and no doubt "Get All Records" + Filtering is going to be heavier than a "Has Record" with a singular conditional, and at the backend it's probably much quicker to process than having to process an additional filter…
4. Log syntax errors in requests. No idea why this doesn't occur currently, as it's a headache to debug - especially when the requester is bubble.io - since it doesn't actually log the body anywhere, making troubleshooting near impossible when both Xano and Bubble don't log that the actual request body was.
5. Add a "switch" conditional block, rather than requiring nested "if/then/else" statements. This would make my blocks soooo much more readable and easier to manage.
6. Create a "shared" Enum option - allowing re-use of Enums in multiple places from a shared set, rather than having to open two tabs and copy/paste text in DB fields and multiple APIs the allowed Enum values.
7. Support for appending to an array in a DB query conditional. For example, if I am checking a user role is in an array of "whitelisted" roles - I should be able to simply enter "user.role" "in" "[] push "Admin" push "Vendor", similar to what is possible in a variable. As it stands, having an option of doing a conditional check against an array in the DB query is completely pointless, since it's not possible to dynamically build an array in a DB query block due to this basic missing feature.
8. Copy-paste functionality of blocks. I cannot tell you how many times I simply clone an entire API and delete 90% of it due to simply wanting a consistent structure. Yes, I'm aware this is potentially one of the use cases for snippets or functions - but that's a lot of hassle compared to a simple CTRL-C-CTRL-V when I might only follow that structure for a small handful of APIs. This copy-paste functionality should also work between multiple tabs, as I usually work like this so I can easily reference the schema or other APIs.
9. As others have said… stop auto assuming "id" as "auth.id". I use "id" in virtually every table, so this gets frustrating quickly when diagnosing random unexpected outputs. Same goes for any inputs - I often name my inputs the same as the columns, and this almost always causes a headache. I'd much rather assume the field is in the table, instead of assuming from the input - since most the time I'm referencing a variable or a table column. (as an aside, is it too much to ask to shrink down the physical size of the details listed in the side panel? If you change a lot of values on a variable, it gets massive quickly).

As above, I'm loving using Xano and plan on moving forward with it for years to come (as long as the pricing model doesn't turn into a consumption base! I'd rather pay a slightly higher monthly rate than consumption pricing like backendless or bubble - as those models are simply killers for a startup B2C.). The above would make fantastic additions to the platform, and I don't see anything I've listed as extensively complex requests, tbh.

jakespirek

Hi @aemondis,

Thanks for taking the time to write all of these thoughts. I've shared this with the team.

I'm glad you're loving Xano so far, and we hope to make it even more delightful to use. 💪

aemondis

Just remembered another one I forgot to add to the list…

10. Don't throw errors when a filter such as "to_lower" is sent a NULL. When I have a filter that is applying a lowercase transformation to some text, there are times when it will be NULL - and I really don't care that it is empty. The workaround? A whole layer of conditional checks and variable pre-seeding to handle conditions just to address this. This is particularly problematic for filters on inputs, for example converting to_lower at that layer.

N.B. I do wonder if this is a bug? The return message is not nicely formatted like other error messages in Xano: Exception: xano\extension\xs\Strings::xano\extension\xs\{closure}(): Argument #1 ($msg) must be of type string, null given.

aemondis

Thanks @jakespirek, you must have commented before I refreshed the page! I just added 1 more after your reply, but it might be a bug - not too sure. I have seen it a lot, almost always on a conditional check that uses the to_lower filter on an input (heavily used in my case, due to having to handle a lot of free text inputs) - and usually need to build up an extra layer of conditionals to handle it.