Very interested in trying:
subdomain: theresidesk
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?
@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 {{ listView1.data[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[lbSections.selectedItem.id][i].email_subject
const newValue = listView1.data[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", lbSections.selectedItem.id, i, "email_subject"], newValue)
}
But if I could get the the whole child object like I can do with form1.data
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.data != item.initialData) {
// Set the new value into the outreach_plan
outreachPlan.setIn(["outreach_plan", lbSections.selectedItem.id, i, item.data)
}
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.
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:
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.
Hi,
Hover on those two new components would be very nice.
Thanks
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.
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).
Hi,
Super duper.
Going in Styles and {{self.hovered ? "#D1D1D1":"#FFFFFF" }}
I would be nice to be in the Appearance section.
Regards,
I have a new client who needs needs this, could you turn it on for sjap.retool.com please? Also if you have access, could you also flip the switch for the Multiplayer beta? Thanks!
Awsome!
Now that same client just told me this morning that they decided to move the project over to a different org.
Could you kindly add courierrx.retool.com to multiplayer and Listview beta?
Thanks.
Both enabled! You will have to go to Settings > Beta and turn multiplayer on there