It is especially useful to hear from users who have hit some friction with the scope barrier, which prevents you from accessing List View children from components outside of the List View. Here are some things we are particularly curious about:
Your Use Case: What are you using the List View for?
Write-Back Setup: If you've set up interactions to write changes back to your database from the list view, we'd love to hear about your setup and building experience. More specifically:
What triggers the write-back?
What data are you writing-back?
Expectations: What functionality around write-back would improve your experience?
Please feel free to share your feedback via this thread or DM me. Thanks so much!
An example of what you can build with our new List View and Grid View components
The number 1 biggest issue with Lists (other than my other open issue) is that we cannot embed modules.
Its such a core use case to make a module to display a certain type of information. Currently it basically means if I want to use a list, i have to build the list contents every time i want a list of something in my application, instead of just reusing a module.
Using new list view with hopes the performance is snappy. The previous suffered, especially when it came to too many input components. It was very laggy to render and after when entering values into an input component there's a delay of a few hundred ms.
I'm using the list view with all types of input components that ideally upon setting the default value of an input component from my db, the user has the ability to change and update the values into the db. I've experimented with A) each component Initiating a Change event handler that updates the one value, and B) a button and queries to capture all changes in the list and then run it all together.
Ideally I want A if it was performant and slightly easier to setup, a little tedious with temp variables..
B does require a lot of setup too with side queries, before finally passing it back into the db.
The data I'm rendering and writing back is dynamic, imagine Products with varying attributes..
Product A has 3 number attributes
Product B has 2 number, 3 date and 5 text attributes
List views allow to render the rows but because each Product has different attribute types you have to check the type for each to hide the non matching attribute. Afterwards the updates/ write back needs to be setup for each type.
I wish there was a more dynamic everything input component, that allows for its input type to be specified (date, number, string), with formatting settings available. This would replace having each of the 3 types in a listview and then setting hide/ show based on more logic. The everything component would expect the input type value passed from the db, in a column.
I had mentioned in an earlier post that treating the ListView data in the same way as a form (with .data and .intitalData) would be a good way to manage its contents.
Treat the ListView's data like you would a table's. Specifically it would have .changesetObject and .changesetArray properties along with Edit handler (and New handler once the new Table also gets that).
Treat at repeatables as a specialized row type. Each repeatable has the same functionality as a form per my earlier idea, but the collection is treated mush like a table.
I could also see a use case for selecting a repeatable "row" as well as having Filters.
Another thing:
I assume you are working on a repeatables version of the Re-orderable List or possibly adding re-orderable functions to the ListView to replace it. I have three apps that I hacked in re-ordering the ListView, building that in would be sweet!
Hello, I use a list view to display chat conversations. the virtualization for loading and scrolling through large conversations was intriguing. I'd like to see the addition of onChange() and the ability to dynamically disable the component. not having onChange() makes things a bit difficult. any query or action that can cause the loading of a new conversation or the addition of a message I have to find a way to scroll the list view. It works, but duplicate code everywhere can give programmers nightmares and PTSD
@andoliveyou is there any update on the capabilities/features of the new repeatable components? or somewhere i should bookmark to look out for updates w this type of information?
i would second this. having issues with changed data handling and can't find an easy way to achieve this, see also here: ListView / Modify Values and save
Edit:
After some more digging and experimenting, i found a solution and i also incorporated the idea of having a "changeSet" object which can be used. The solution can be found on the link posted above.
We are using list views to allow the user to edit & reorder lists stored in our DB. You can think of the underlying data as a list of ToDos (for the sake of simplicity), stored as objects as an array with multiple text properties. In Retool, this is mirrored by having one container per ToDo which contains text input fields for each property as well as buttons to remove as well as move the ToDo. The listView provides fantastic functionality to not only display our data dynamically, but also in a very sleek & beautiful way.
We are storing the list of ToDos retrieved from the DB in a temporary state. All FE interaction with the list (rearranging, deleting & editing text) is directly stored in the temporary state via event handlers executing custom scripts. On button click by the user, the updated data (= the Array of ToDos) stored in the temporary state is written back to the DB all at once.
Currently, the one main issue with ListViews is not being able to reset the state of the components inside them. A typical issue is that a user updates the text in element two and then switches the position of element two with element one. The textInput in element one has not been changed, so resets to the new default value which is the text updated by the user. The textInput in element two has however been changed by the user directly, so it doesn't default back to the default value of the old element one, and keeps on displaying the text updated by the user. This means that the textInputs in element one and two now display the same data, whereas the underlying array stored in a temporary state contains the right data.
In the old listView component, this would have been solvable by resetting each textInput in the listView. This is unfortunately not possible anymore, which makes the new listView component practically unusable for rearranging data.
I've been trying out the new list view today. At the moment, I am mostly using nested list view to create grouped, formatted reports (recreating reports that were created for the old Access database our new Retool app is replacing). These are often very long, so there are a lot of components. I'm noticing a huge improvement in performance from the previous version of list view right away--everything renders quickly without any lagging or freezing when the list is too long.
The main issue I'm having is with the scroll bars. I am building my list views in modals, and in the previous version, the only scroll bar was on the modal itself. Now there is a scroll bar for each of the nested listviews, which clutters up the report and means that using utils.downloadPage with the parent container as component to include no longer includes the full content of the list views in the downloaded pdf, only the parts that are currently visible with the scroll.
those scroll bars are absolutely evil. it might just be how I'm using it in a drawerFrame, but if I have the listview component selected then the UI enjoys doing this weird seizure thing where it adds a scroll bar then removes it really fast and continuously:
it flips through these 2 'frames' very fast and since scrollbars change the x pos/width of stuff clicking on child elements can get annoying without using the Component Tree. selecting any child or parent element stops the madness btw.
Hi, this thread seems to be relevant. Essentially, it describes expectations of the ListView's behavior regarding an enclosing Form component and/or editable sub-components.
The fact that we cannot use modules in repeatables is a major drawback and severely limits their use (for now), because it means you can only use them for the very simple cases, and for us most of these simple cases are already well covered by a table.
Same as @cstork, I cannot fathom why a simple editable list view needs so many hackarounds, I could have done it within 10 minutes using React but threading the needles in Retool takes more than an hour?!
