I would like to see functionality added to list blocks on Softr that allows you to configure the maximum number of records that can be returned by a list block.
Use case: You have an app with plan/subscription levels that each allow you to have a different number of books in a library-style app. A user upgrades from the highest plan to the lowest plan, but they still see all of the books they added while on the highest plan because Softr doesn’t allow you to cap the maximum number of records displayed in the list block.
There is a way to achieve this in Airtable views, and then configuring Softr blocks to reference the respective views for your user groups, and finally using (the recently enabled) block visibility option to only show the correct block (list/table) to the matching user group.
This works well for types of records but not for quantity of records.
In my experience from testing (using the library-style app example above), if the highest subscription allowed access to premium books and the lowest subscription allowed access to non-premium books, you could definitely do as you suggested using views in Airtable that filter for each type of books and then using one block per view.
Where this doesn’t work so well is lets say the app had a “Read Next” list of books a user wanted to read next. The highest subscription lets you add 100 books to your Read Next list, the lowest subscription only lets you add 10 books. If a user has 50 books on their Read Next list and then downgrades from the highest to the low subscription, there’s no way to limit list blocks from showing more than 10 books.
Using user groups to know when someone has reached the maximum number of books allowed on their Read Next list and to hide “Add to Read Next List” buttons works to prevent someone from exceeding the limitations of their subscription in the first place, but in downgrade situations (where you previously had a higher limit) this doesn’t work.
The only work around I’m aware of is to use Zapier or Make to create an automation where when someone’s subscription level changes to update a field in Airtable, which in turn can trigger a script to run that marks 40 of the 50 book records on the Read Next list as hidden (delete those records), and then include Hidden/Not Hidden field in your view filter.
A lot of extra steps (especially when Softr won’t give us access to users’ subscriptions or products in Airtable) to solve a probem that Softr could fix by adding a maximum records allowed to be displayed feature.
I’m already using this work around, happy to do so, just wish it was easier.
If there was a maximum number of records feature, what would the criteria be for only displaying a limited number of a larger dataset? So, with your example of a downgrade from 50 to 10 books, how would the 10 displayed be selected and the other 40 de-selected?
There may still be a solution within Airtable. It is a very interesting scenario, similar to one of my own
Multiple ways to do it depending on how much preference you want to give a user who downgraded, but the simple approach would be to:
Visible Records: 10
Sort Records: By Created Date in Descending Order
Filter Records: Where User ID = Logged In User’s User ID
This would show their 10 most recent books.
I imagine that most users would be happy with this, and technically if they deleted one of these 10 books, then one of the books from the 40 not visible could automatically fill in it’s place (depending on how you setup your logic), so the 40 books aren’t entirely lost.
But again, multiple ways to approach this. During downgrade process you could prompt a user to select the 10 books they want to keep visible, prompt them to delete 40, etc.
Same approach I have taken
An alternative is to run a script in Airtable to rank the users records, triggered on downgrade; then sort by rank, ready for an Airtable view to filter records with rank-field-value <= 10
There’s also the option with a List block of Items per page … so this could be set to 10 and the “see more” button could be hidden/disabled using some targeted JS/CSS, I think.
Update: delete the “See More” label and the button disappears
Great idea removing the See More button, looks like a solid work around. Will have to test this for myself.