New: ListViewV2 beta

Hi all, we are excited to announce the beta launch of ListViewV2!

With ListViewV2, we aim to significantly improve performance and developer ergonomics. To improve performance, we have implemented virtualization similar to the new table component. For ergonomics, we updated how data is passed to use a data source and have exposed the {{ item }} key word to reference each array entry rather than relying on {{ i }}. We are still busy working on adding more features and improving the ease of use, but we would like to get some feedback from you with this beta launch. If you are interested, please reply here or DM me with your retool subdomain. Note that this is cloud only.

A few more things to note for this beta:

  1. The new list view will appear as a new component - there will be no change to your existing list views when you opt into the beta.
  2. While the probability is low, we may make backward incompatible changes that can break your app until we publicly launch this feature. We will be sure to make an announcement here in this thread when it happens.
  3. With virtualization, we have removed the ability to reference components within the list view from outside the list view (but within the list view the components can still reference each other), or indexing these components (e.g. textInput1[I] will not work). The exception is that the JavaScriptQueries will be able to reference the components (but still without indexing) if they are triggered by components from within the list view. When this happens, the reference will point to components in the same row.
  4. We are working on supporting write-back patterns that may have been blocked by the change above - please let us know if you have any feedback or specific patterns you would like us to support.

Would love to test this out! I have a new applicaton that relies heavily on dynamic amounts of listviews with alot of internal components!

domain is



Sounds great! Love to try it out.



1 Like


1 Like

@avr done! @ScottR @dbows can you let me know what domains you want to enable on? Feel free to reply here or DM me.

Also @avr since you quoted the first point - do you have any use cases that you want us to keep in mind?


Very interested in trying:

subdomain: theresidesk


Thanks for the access @yyjhao, appreciate it!

I accidentally quoted when replying on mobile, didn't not mean to focus on the first point.

In the component overview I can no longer see the default list view. Could you please enable the default component again so I can review these side by side?
Screenshot 2023-10-06 at 11.52.24

1 Like

@avr just toggled a flag for you - you should be able to find the old list view in the deprecated section.


One thing I noticed which may help with #3.

A triggered query sees i as it does with the current ListView, but it does not see item. You can get around that by using a Run Script event and triggering the query with addtionalScope, but that is no fun.

However, if you pass item you may need to worry less about having access from outside of the ListView context. All of my use cases so far only need access to the ListView within its own context.

I also have a suggestion - I would even call it a critical request: Follow the pattern of the Form component.

The Form data key property should pull that property from item like a form's child components pull from the form's Data source.

In addition there should be an equivalent of the Form's Data property so we can the current values of the ListView's children along with an Initial data property. Initial data is les critical as we can still access the ListView's data source.

Using the existing form pattern would make using the ListView much easier for data editing use cases.


Thanks @bradlymathews for the feedback!

Agreed that {{ item }} should also be accessible from queries triggered within List Views. We'll work on adding that -- in the meantime, you should also be able to use {{[i] }} to access the same value.

In regards to using similar patterns for List View as the Form component, such as using the data key property to aggregate a data of the List View's children, agree that this would be useful! We're considering how this feature would work and we'd love to hear your use case -- if you're willing to share here or through DMs/email, would love to hear it.

Most of my uses for list view are as a more formatted version of a Table component with full CRUD and usually with a JSON object array source (like from a jsonb column type.)

See my Show and Tell on ListViews: Full advanced List View component example

So what I do is move that JSON into a global var and point each child component to an object property. And then when a user makes changes to the component I fire an event that updates the global var. Sometime I will also do a silent database update in the background which pushes the entire array back to the database.

Right now my Default values on the child components look like this: {{outreachPlan.value[i].message}. And I need a separate onChange handler for every child component like this:

// Get the existing value and the old value
const oldValue = outreachPlan.value.outreach_plan[][i].email_subject
const newValue =[i].txtSubject

// Only make the change if teh values are different  
if (newValue != oldValue) {
  // Set the new value into the outreach_plan
  outreachPlan.setIn(["outreach_plan",, i, "email_subject"], newValue)

But if I could get the the whole child object like I can do with I can use a single event handler for all changes. And if I can get the intitialData, my handler is much simpler.

// Only make the change if the values are different  
if ( != item.initialData) {
  // Set the new value into the outreach_plan
  outreachPlan.setIn(["outreach_plan",, i,

It generally makes ListView operation easier to work with and reason with in the same way that Form did the same thing vs the old form.


@bradlymathews Nice to see your mindset and use of global variables combined with updating a database silently. I like doing that too but was never quite certain if it was a real 'practice'. It always seems suggestions revolve around updating the database and then immediately querying the data back it which feels like waste to me. I like driving everything off data saved into variables. It makes queries more central and reusable.

1 Like

Yeah, Retool data components like the Table do not have a good mechanism for keeping data state locally managed - they assume you will be requerying the datasource in order to ensure data synchronization.

Some way of maintaining sync between client and database is especially important in a multi-user environment. However, Retool does not have a good answer for handling multiple users editing the same record anyway. So it becomes s moot point.

Therefore why not keep local state managed somewhat independently of the database under two conditions:

  1. Your client data methods are robust.
  2. You do not expect multiple users to edit the same record.
  3. You have a way to check database state.

I have not had to figure out how do deal if #2 is not true within a Retool context. Yet.

Do #1 and you should be golden.

And just add a Reload button somewhere to cover #3.

1 Like

I would like to have a go with this new module.



Hover on those two new components would be very nice.


1 Like

Hi @MicExpert Can you share an example use case? Thanks for the feedback!

1 Like

We use ListView to achieve a customizable appearance similar to a table. While hover functionality is commonly used in tables, it would be beneficial to implement this feature in ListViews as well.

1 Like

Works for self host or not yet?

Hi thanks for the feature request! Containers in Retool have the hovered property that you can use to implement a hover state for the new List View. You can also add click event handlers to containers to open up detail views (like Drawers or Modals).

container hover