lets imagine that we have 2 independent data collections:
menu (contains labels + links [])
posts (contains text [])
By default Strapi gives me 2 endpoints, one for menu and another for posts. That's fine, but how I can combine this two (or even 10+ small data collections) in one Strapi REST API response?
I'm new to Strapi so need most simple and effective solution. I know that possible to make a custom endpoint but in this case I should manually add/remove any collections inside Strapi config - think its not a true way.
Thank you for your time!
You can also create another collection e.g. agg_collection that has relations to both collections so you can retrieve them by calling api/agg_collection?populate=....
Writing a custom endpoint is the preferred solution I suppose, but the question is; do you really need to have it in a single request?
Related
We are running DRF in combination with django filter to narrow down list view results.
As filters and filter options are increasing, we would like the frontend to display only the available (the select-able) filter choices.
Simple example: There are a lot of products but none is green. The frontend should be able to disable/hide the checkbox for green by asking the DRF
More complex example: There are a lot of products and all of the red ones are small. If the user selected the red filter (e.g. frontend calls /products/?color=red) there is no need to bother the user with filters for medium and large.
Currently, we are about to create a custom implementation based on DRF's options method: That is manually checking for available filter choices depending on the current query set and returning this info as the "actions":{ "GET": {...}} dict using e.g. custom metadata.
We could also augment the GET response similar to the pagination API which already adds count, next and previous to the answer.
However, this seems to be a rather common use case (e.g. in online shops) and thus I was wondering if there is a django-filter/DRF-onic way (a best practice) or even a library for that.
I am having someone create a bunch of templates (themes) for a website, and want to keep data passed to the views flexible.
For example, with the users in the system I want to be able to supply the top x users and the most recent x users. In my controller I don't want to pass this data to the view, because he might just need the top 5 users and I am querying the top 10 - or worse, I might only get the top 5 and he wants the top 10.
I am thinking there would be two ways to do this.
1 - A view "helpers" file, which could contain functions like. getTopUsers($count) and getNewestUsers($count) which would do the model / repo call.
2 - Create a view presenter to keep these extra functions. I've had a look and there seems to be two main presenter packages - https://github.com/ShawnMcCool/laravel-auto-presenter and https://github.com/laracasts/Presenter
Maybe there is a better way?
There could be half a dozen of these, for various models...
I would pop some client side code into your views and access a route to a controller action (which returns JSON by default) and conditionally add that particular snippet into your view (via a variable passed to the view that determines if the person is logged in). Then you can apply an auth filter to your route to protect it.
Note: with this approach you can pass url parameters to your action. This means you can tell your controller to limit your results more easily.
This is a very interesting question, my friend. What I can think of is the following
1) cheap way, just query 10 or whichever the biggest number, and then pass a variable $count to the view or let view pass a variable to the sub view
2) api call, if you'd like to do AJAX call, then as others suggested, you could just design a new route, getData?count=5.
Normally it's not easy to meet all requirements, and practically speaking in the prototype stage, it'll be more cost-effective to write fixed function like getData5, and getData10, or just make two pages :) it'll be a lot faster than coming up another new architecture design and then realize in the end nobody really uses them.
Example:
I am writing a Meteor app that deals with a list of blog posts. All blog posts are stored in a collection called 'Posts'. I use Iron Router for routing.
I want to show the user a list of all the posts created by a particular author. This list will be displayed using Spacebars. Therefore, I need to provide the data to the template.
Problem:
As far as I know, there are two ways to do this:
Using template helpers
Using the 'data'-property of my route
Option 1 example:
Template.postList.helpers({
postsToDisplay: function(){
return Posts.find({author: 'someAuthor'});
}
})
Option 2 example:
//Inside my route
data: function(){
return {postsToDisplay: Posts.find({author: 'someAuthor'})};
}
Question
Are there any significant differences between those two methods? Is there a reason to prefer one over the other? Does one deliver better performance?
Thank you very much for your answers!
Are there any significant differences between those two methods? Does one deliver better performance?
Not really, it's just design choices after all.
Is there a reason to prefer one over the other?
I would stick to the iron-router + data method, here is why :
You can use waitOn to actually display the list only when data fetched from the server is ready, using Router.onBeforeAction("loading") and a loadingTemplate improves overall user experience.
You can design a data agnostic postsList template that you can feed with different contexts.
The last point is particularly interesting, because it allows you to define a reusable template that you could use to display the list of recent posts, the list of posts in a category, the list of posts by a certain author as you want to achieve in the first place, etc...
<template name="postsList">
{{#each posts}}
{{> postListItem}}
{{/each}}
</template>
Here you could define posts as a helper of postsList, but it's better to let the parent template that will call postsList assign posts to whatever it needs to.
template:"postsList",
data:function(){
return {
posts:Posts.find({
"author":this.params.author
})
};
}
This design pattern allows us to define a route that provides a data context which represents the list of posts by a given author, but you could also define another route providing a data context which will list posts by category.
So by moving out the data provider role from the template helper to the route definition, we have a much more reusable template, which is nice.
I am using a filter to apply object level permissions to a collection. Resources in a second collection have a many-to-many relationship with the first. On the browsable API, when creating resources in the second collection, the user is presented with a list of resources from the first to link it to. However, this list is not filtered, so the user can see values that they should not be able to see.
I've poked around the documentation and source a bit and I cannot see a way to add filtering to the queryset that generates the choices without overloading or modifying a bunch of code to pass the request data down (probably removing some of the collection specific data on the way) and then apply the filters.
Is there a better way to achieve this?
Currently there's nothing to support this out of the box. Pull requests are always welcome. If it's something you want to work on you may want to either open a ticket on GitHub or hit up the mailing list to discuss it first.
I'm making a pretty standard AJAXy (well, no XML actually) web page. The browser makes a bunch of API queries that return JSON to run the site. The problem is, I need to add to the API interface each time the page needs to do something new. The new API interface is usually little more than a database query followed by mapping the returned objects to JSON.
What I'd like to do is to get rid of all that server-side duplication and just have the page make database requests itself (using the model interface), but in a way that is safe (i.e. just read only ones). I think this would amount to an interface for constructing Q objects using JSON or something like that, and then send that up to the server, run the query, and return the results. Before I go making my own half-broken architecture for this, I'm wondering if this has already been done well. Also, is this even the best way to go about eliminating this duplication?
Thanks
Search multiple fields of django model without 3rd party app
Django SQL OR via filter() & Q(): Dynamic?
Generate a django queryset based on dict keys
Just replace with operator.and_ where appropriate.