You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that some of the amp4email codebases I've looked at encounter and need to compensate for limitations around nesting amp-lists. for example, a list of discussions each containing a list of comments
I think one side effect of this problem is that it stresses the use case for single item lists. When you can't define nested lists you tend to need to flatten your data in creative ways. You focus your UX on the most important list, and join in individual data points as needed
Not filling this feature request seems to be because of risks on self referencing lists, and potentially also rendering nested mustache templates and/or amp-lists
Solution
Allow amp-list to reference a data source via items, or a reserved src format like how binding an amp-list to an amp-state works. This solution just focuses on what I think is an easy and understandable way to define nested amp-list syntax as someone developing with amp, I'm guessing rendering nested lists and their bindings will be the limiting factor and more important question...
Consider binding amp-list xhr response to amp-state under the hood to move enforcement of json structure / self referencing json nestings to that silo, and also potentially merge nested amp-lists to a similar flow as binding an amp-list with an amp-state, the child amp-list would treat its parent amp-list's internal amp-state as its src and use items="..." to drill down a level, keeping the prevention of recursive json structures under the responsibility of amp-state
Nested lists could use slightly different syntax
xhr endpoint (https://www.example-api.com/nested) returns json - an array of discussions, each containing who their assigned to, if their resolved, and all comments made in the discussion
🚀 Feature Request
Problem
I've noticed that some of the amp4email codebases I've looked at encounter and need to compensate for limitations around nesting amp-lists. for example, a list of discussions each containing a list of comments
I think one side effect of this problem is that it stresses the use case for single item lists. When you can't define nested lists you tend to need to flatten your data in creative ways. You focus your UX on the most important list, and join in individual data points as needed
Not filling this feature request seems to be because of risks on self referencing lists, and potentially also rendering nested mustache templates and/or amp-lists
Solution
Allow amp-list to reference a data source via items, or a reserved src format like how binding an amp-list to an amp-state works. This solution just focuses on what I think is an easy and understandable way to define nested amp-list syntax as someone developing with amp, I'm guessing rendering nested lists and their bindings will be the limiting factor and more important question...
Consider binding amp-list xhr response to amp-state under the hood to move enforcement of json structure / self referencing json nestings to that silo, and also potentially merge nested amp-lists to a similar flow as binding an amp-list with an amp-state, the child amp-list would treat its parent amp-list's internal amp-state as its src and use
items="..."
to drill down a level, keeping the prevention of recursive json structures under the responsibility of amp-stateNested lists could use slightly different syntax
xhr endpoint (https://www.example-api.com/nested) returns json - an array of discussions, each containing who their assigned to, if their resolved, and all comments made in the discussion
would use amp syntax:
Alternatives
Handling all nestings via a combination of flattening & creativity in the json response and in the amp implementation
The alternative is shorter at the top level but would be longer at lower levels within each list, and harder to follow the flow of
The text was updated successfully, but these errors were encountered: