Add additional glob population options
Nils Lundquist
This feature is utterly irreplaceable for me. Without it making pages with heavy use of nesting / relations isn't worth the effort. Our Strapi instance is used during a static site build process so performance / request times are inconsequential.
Your video on population indicates that nested globs are "very high priority" and will be available in V5: https://www.youtube.com/watch?v=aJ2pYRN8DH0
This feature didn't make it into V5? Seen that it has been discussed for more than 2 years. Unfortunate to think it's unlikely to be available till V6.
Derrick Mehaffy
Merged in a post:
Populate any number of nested levels
A
Adam Schuld
The strapi team has allowed the nesting of components multiple level deep, however there's no way to grab all of those nested components in an intuitive manner.
Currently there is a
populate=*
or combining of multiple specificpopulate
parameters. It would benefit many of us to have very simple convenience operators. I'd like a very simple *.*
to indicate all 2 level nested components. Or even deeper *.*.*
. Two suggestions
:- **indicates "give me every level of nested I'm aware of the consequences"
- testDZ.*.*"give me two nested levels deep on my test Dynamic zone"
As a developer, I'm aware of the risks of slow queries. I'd rather have slow queries than extremely complex ways of relying on dynamically generating populate parameters. This enforces the UI to know ahead of time what the structure of the nesting is. It's contradictory to the concept of dynamic zones.
This is your suggested approach according to the documentation:
populate[testDz][on][test.test-compo][fields][0]=testString&populate[testDz][on][test.test-compo][populate]=*&populate[testDz][on][test.test-compo2][fields][0]=testInt
I love you all, I'm super appreciative of everything else about Strapi, but this expectation is mildly infuriating, highly brittle, and in no way scalable.Derrick Mehaffy
Merged in a post:
REST API: combine populate="*" with specific deeper-level (2+) populations
T
Thor Galle
The
populate="*"
feature is very useful to populate all relations until 1 level deep.But this solution falls short as soon as you have just one field for which you want to populate 2 or more levels. From this point on, you need to explicitly specify
every
single relation you want to populate, also the 1-level relations which you could previously cover withpopulate="*"
.How could this look like?
A query like this, with 8 x 1-level populations and 1 x 2-level populations:
populate: {
curator: {
populate: {
picture_hiking: true, // 👈 the only 2-level populate I need here
},
},
// 👇 all these fields have to explicitly mentioned, and amended when you add some
departure_station: true,
arrival_station: true,
trip_days: true,
track_url: true,
cycling_nodes: true,
preview_track_url: true,
track_gpx: true,
image: true,
}
Could be transformed into this:
populate: {
curator: {
populate: {
picture_hiking: true, // 👈 the only 2-level populate I need here
},
},
},
auto_populate: true
I'm suggesting a
auto_populate: false | true
property here, which can always appear as a sibling next to the populate
property, and which takes over the role of populate: "*"
.Or, if 2+-level auto-population would be considered (see referenced feature request):
auto_populate: number
, so that auto_populate: 2
would auto-populate until 2 levels deep, and you could still manually specify a 3-level population.Or, a syntax where multiple population specifications could be provided, but that seems more convoluted:
populate: ["*", {curator: {populate: { picture_hiking: true } } }]
Why this is a problem?
It's a little annoying to have to explicitly list fields in a query, if you know that you're going to need them all anyway (and a wildcard would thus suffice).
The limitations of the auto-population feature can also lead to a skewed mental model: it's sometimes possible, and sometimes not, and it's your responsibility to remember how the limitations affect your logic in each part of your app.
In your front-end, you might abstract away Strapi REST API queries in functions. For some queries, where you only need populated data 1 level deep, you could use the
populate="*"
inside a data-fetching function. If you add a field to the content type, you don't need to update your query function, the front-end immediately has access to it. Magic!For _other_ data-fetching functions where you needed 2-level population _somewhere_, this does not apply: you can not formulate your query in such a way that 1-level deep relations are auto-populated. This makes it easy to forget to update the query if you add a relation to the content type much later, leading to missing data and bugs.
References
- See this forum post: https://forum.strapi.io/t/rest-api-combining-and-specific-field-populate-for-a-dynamic-zone/28155
- This is also tangentially related to this feature request: https://feedback.strapi.io/feature-requests/p/populate-any-number-of-nested-levels - although I'm not suggesting arbitrary-level auto-populations here, just that the existing 1-level auto-population feature can be combined with manually specified 2+ level populations.