[Bug]: Bindings to Table1.newRow throw error at all times unless a new row is in draft

[GreenFlux]

Is there an existing issue for this?

• [X] I have searched the existing issues

Description

When constructing the body of an API with bindings to Table1.newRow, every binding throws an editor error until you begin entering a draft row. The errors resolve while creating a row, but they come back as soon as the row is saved or discarded.

It should be expected that the newRow won't always be there. And the API body template should be simple and not need logic checks for each binding.

Can we hide these errors unless a row is actually being drafted and there is still an undefined reference to another field?

---

As a workaround, you can use Lodash _.get(), to return the value at any path of the newRow object, and also provide a default in case it is undefined. It's much cleaner than the alternative ternary or if block needed to avoid these errors.

Instead of this, which normally throws errors:

{
    "Item Number": Table1.newRow['Item Number'].value,
    "Product Name": Table1.newRow['Product Name'].value,
    "Price": Table1.newRow['Price']
}

You can use, this format to avoid the errors:

{
    "Item Number": _.get(Table1.newRow, 'Item Number.value', ''),
    "Product Name": _.get(Table1.newRow, 'Product Name.value', ''),
    "Price": _.get(Table1.newRow, 'Price', 0)
}

Steps To Reproduce

1. Enable adding a row to a table
2. Start entering a new row but don't save
3. Reference the columns in an API body (Table1.newRow.fieldName)
4. See that there are no errors referencing newRow or nested properties
5. Discard the new row.
6. See that there are new errors for every binding that was working while drafting a row.

Public Sample App

No response

Environment

Production

Issue video log

No response

Version

Appsmith v1.9.57-SNAPSHOT

[rahulbarwal]

@GreenFlux can you please share a video of this problem?

[GreenFlux]

@rahulbarwal I just realized I left out some info in this issue. It's only a problem when the column name has a space, which prevents using dot notation. This means that optional chaining can not be used before the column name.

Without optional chaining, the user has to add a ternary operator or an OR || operator to provide a default value for every newRow field reference, which adds a lot of complexity to the API body.

Considering the error clears as soon as the Add Row button is clicked (without inputing any values), could we just keep an empty newRow in the background at all times, to avoid the errors even when there is no draft row being created?