[Feature]: Option to modify the order of preference for hydration of meta properties

[ashit-rath]

Is there an existing issue for this?

• [x] I have searched the existing issues

Summary

When a widget is mounted for the first time, the meta properties of the widgets are hydrated using the default values of the widget.

This feature aims to modify this default behaviour of looking only into the default values. Instead the widget can provide an order of preference to the evaluation to first look into the existing meta value (if present) and then the default values for hydration.

Why should this be worked on?

The List widget v2 creates widgets on the fly while navigating to different pages. When a page is modified the previous page widgets are replaced with the new page widgets on the unevalTree but the meta properties of the removed widgets are still persisted. When the user navigates back to the previous page, the widgets are expected to be in the same state as they were before and the state primarily depends on the meta properties. In the current implementation of the evaluation, the new widgets for the previous page navigation are hydrated with the default values so the existing meta properties are lost in the process.

[bharath31]

The List widget v2 creates widgets on the fly while navigating to different pages.

@ashit-rath could you please elaborate on this?

@Rishabh-Rathod can you share a rough estimate for this task? This will help us during our next sprint planning.

[ashit-rath]

@bharath31 Let me know if this doc helps https://www.notion.so/appsmith/Meta-Widgets-DRAFT-9e7eb03174c945df80d7d7dbe7be3a67

[ohansFavour]

first look into the existing meta value (if present) and then the default values for hydration

@ashit-rath What you described as the solution to this problem is actually the current way of hydration today. The main cause of the issue here is that in List widget V2, only list items present in the viewport are added to the unEvalTree (which is expected). When navigating back to a previously present list item (which got removed from the unEvalTree after navigation), although its previously cached meta values are added to the unEvalTree, during evaluation, since a "new" widget (metaWidget) was added to the unEvaltree, all its paths requiring evaluation gets evaluated this also includes properties that can override meta values (like the defaultText of the input widget). This then causes changes to the meta values which we had populated using the cache prior to evaluation.

[ashit-rath]

@ohansFavour Agreed, I was looking for a new extension for it. Let me know if I am wrong here Current way: New widget re-appears

1. meta property hydrates by some property if the property has some value (defaultText)
2. meta property resets if no default value is defined (post evaluation)

Proposed way: New widget re-appears

1. meta property hydrates by value present in meta reducer
2. meta property hydrates by some other property if the property has some value (defaultText)
3. meta property resets if no default value is defined (post evaluation)

[ashit-rath]

@satbir121 I can still see the PR to fix the regression still open. Any particular reason to close this?

[ohansFavour]

Fixed here