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
To make template more easier to write, we should identify common patterns (even if opiniated). Some ideas I'm often using:
A base built-in Criteria object that would come with additional functionalities. For instance, a pattern I like for sorting is using a query param "sort", in the following format: "sort=date,-id". This would sort by date in ascending order, then by id in descending order. The base Criteria could parse such strings.
Helper for parsing "expand". If you have a not-so-simple APIs, having the ability to asking other resources is often absolutely vital. For instance, if you display a list of users, and want to display their associated subscriptions, you could ask the following request: "/users?expand[]=subscription". Internally, you could read this and do an optimized query to load the subscriptions. However, expand can be nested, so if you want to load the subscriptions WITH the plan: "/users?expand[]=subscription.plan".
In view rendering template, I'd like to be able to do that:
In the previous example, if the expand is "subscription.plan", then hasExpand will return true, and reduceExpand on 'subscription' will return 'plan' (the part that comes after subscription).
Hi,
To make template more easier to write, we should identify common patterns (even if opiniated). Some ideas I'm often using:
In view rendering template, I'd like to be able to do that:
In the previous example, if the expand is "subscription.plan", then hasExpand will return true, and reduceExpand on 'subscription' will return 'plan' (the part that comes after subscription).
Any other ideas? ping @Orkin @danizord
The text was updated successfully, but these errors were encountered: