Currently I am using the built-in feature to add a new record to a table.
I can not figure out how can I set default values for some columns (I need to do this because I will not allow to modify this columns in some circunstances), when I add a new register, all columns are empty. It seems that when creating a new record the "Mapped Value" property is ignored.
I don't want to create an additional extra Form component to fill out the table, I want to create new records using solely the table interface.
How could I set a default value in a column for a new register?
The user experience for adding a new record via the table interface is generally inferior to using a dedicated form or modal. One of the shortfalls, as @MiguelOrtiz pointed out, is that there currently isn't a way to populate the new row in the UI with default values. On top of that, editing a cell in the newly added row requires that the entire column be editable.
I think your best option is to dynamically mark certain columns as uneditable and then define default values on the database side of things. I hope that helps! Let me know if you have any additional questions.
"The user experience for adding a new record via the table interface is generally inferior to that of using a dedicated form or modal" -> this is an opinion.
In my case, my client wants a record management experience using a table, so the experience for them using a form is worse than using a table... obviously we can not generalize this fact to all users.
If the ability to create new records using the built-in "+" button in a table is an option that the table component allows, it is because it is useful for some users. Every professional project has its own unique requirements.
Regarding the proposal to add a record and then allow editing of the newly added record: I don't want to edit a cell, I want to be able to set some default values in some columns when the user creates a new record using the built-in "+" button of the table component. You have now made it clear to me that this is not possible.
Now my next question is that I would like to know if you plan to allow this possibility in the near future or if this possibility will not be on the roadmap.
I think @Darren was talking merely from a technical point of view and the options that the new record via a table offers.
In any case, I think you can still achieve what you what, i.e. adding a new record with pre-defined values using the "+" button on top of the table. You need to add a custom button to your toolbar buttons, e.g. see below:
IN green I've highlighted the new button I've jsut added which is custom has the exact same icon and Label, but it triggers a query rather than the out-of-the box add row functionality. With your query you can add the row with teh default values that you need, which can be as dynamic as you want them, e..g using current_user.email, date, etc.
I've left in a red box the add row button which should be deleted in your case.
But customizing this way will result in editing a new row, you won't see, for example, the graphical effect that is achieved when using the built-in "+" button, and you'll have to manage certain events manually that are handled when Retool adds the record. In addition, you'll have the new record syntactically added to your query in some kind of collection, which will also result in a lot of code overhead to handle it.
Correct! Perhaps I should have said that it's an inferior developer experience within the context of the Retool app builder, as the built-in option is currently less flexible and lacks certain features. The ability to set default values or to specify certain inputs as editable would dramatically increase its usability, for example!
I'll take this feedback to the team and provide an update here as soon as possible. In the meantime, I hope one of the above recommendations will made for a serviceable workaround.
Thanks @Darren, I have also told my company to ask the Retool team to implement this feature which will surely increase the usage of Retool in new projects and the number of developers in my company.
In the meantime, I hope one of the above recommendations will made for a serviceable workaround.