This post covers an example of filtered functionality in the no-code tool Bubble
I recently ran into an issue where spam NFTs were showing up in my Web3 wallet. Normally, I wouldn’t mind so much because they are easy to identify and easy to ignore, but I found that they were also showing up in customer accounts via data we were pulling from the Rarible API into Bubble. And that was a problem!
Here’s how we addressed it.
Unfortunately, Rarible doesn’t have a way to identify spam NFTs in the dataset they provide via API (at the time of this post). One workaround suggested was to maintain a list of Spam contracts and use it to filter out NFTs associated with these contracts.
It wasn't the most scalable or proactive solution, but it was the best available at the time, so that’s what we implemented.
Implementation
First, we created a new Type in our database called “Spam”. We then created one field for this Type called contract with type text. This is where spam contracts are added.
(Who knows, this list could be data we sell in the future?!)
Important note: Rarible data in the contract field is in the format “BLOCKCHAIN:contract” so to avoid creating complicated matching logic, we added our contract data in that same format to the Spam table.
Once that was set up, we used the :filtered operator in Bubble to modify the list of items being pulled in via the Rarible API.
Our List filter was set to compare the contract field from Rarible data with the exclusion list now present in the database. The resulting data set returns all items minus those whose contract is identified by us as spam.
Breaking down the settings used:
:filtered on the Data source lets Bubble know to filter a list of things by some criteria
contract under List filter is from the Rarible data set
isn’t in is the operator used to compare with the other source
Seach for Spams: each item’s contract specifies the field to compare and ultimately filter on in the Spam table.
And voila! The list of items pulled in now is stripped of pesky spam NFTs.
Comments