Seems like the new repeatable ListView doesn't play nice with Form.
Do the following experiment:
- create a
Form (e.g. form1)
- in the
Form body, add a new Repeatable ListView with the default demo data (Fluffy et al)
- in the
ListView body add a TextInput (e.g. textInput1)
- change some of the text inputs and submit the form
- in the debug console, check the
form1.data - it's empty
- now, add another
TextInput to the form, but outside the ListView (e.g. textInput2)
- try
form1.data again - the lone textInput2 will show up.
Maybe set Form Datakey?
I also tried changing the Form Datakey of the ListView's TextInput to be {{item}}, but it doesn't seem to have any effect.
Maybe store to a Variable using a Change-event script?
I also tried to use the "Change" event of the ListView's TextInput to store the data in a variable - That works, as long as you actually Type something in the TextInput.
I, however, need to also be able to setValue to the text field (e.g. via a button).
So when you click the button and set the text field's value, it doesn't fire the Change event on the text field.
Any ideas?
Hi @Eshed_Gal-Or!
Thank you for noting this. We've been mainly suggesting sticking with the legacy list view for the time being if you need functionality beyond long, read-only style lists.
For some context on the new List View, we launched the new List View before reaching feature parity with the legacy List View. We wanted to provide the option to benefit from the performance improvements as soon as possible, and we wanted to start getting user feedback as we're working on additional functionality.
The new list view still has a notable difference from the legacy one, in that it does't support indexing into child components to access their properties yet (see the scope warning on the launch announcement). This feature is being actively worked on and we are collecting feedback/ideas here. Since the new List View was completely redesigned to have better performance, legacy features will need to be thoughtfully re-implemented.
We will not remove the legacy list view until we are confident that there is complete feature parity between the two, and therefore no reason to keep them both. Even when we deprecate a component (i.e. move it from the list of legacy components to the list of deprecated components), you can continue to use existing components in your apps. We only remove the option to create new deprecated components, and we usually maintain an option to still add new deprecated components behind feature flag - just in case.
But to answer your second question, this solution from our community forum may be a great workaround for bulk updates using the new List View!