I have a record that looks like so:
Item {
itemId: 1,
categories: [{id: 123, categoryId: 657, itemId: 1}, ...]
}
(The item is pulled from rest service based on nestjsx/crud, mostly automatic, and i really want to avoid any changes there.)
ReferenceArrayInput is expecting a flat array, with direct reference to the ids. {categories: [657, ...]}
I'm looking for a way to tell him to look at a nested object property.
Or a hook, that will let me transform the records to the appropriate format.
For the visual part, i intend to use AutocompleteArrayInput
Related
I have a JSON object like {"id1": 123, "id2": 234}, that I pass to a feature file in order to plugin each of the values above for a series of API requests like:
And path `/somePath/${id1}/detail`
And request {"id": "#(id1)", "action": "Reassign"}
My first thought was to use a Scenario Outline, but couldn't figure out how to set the ID's in the Examples table so they were properly read. Then I looked in documentation, and it seems like when I pass a JSON object like this, it should run the scenario for each value automatically. The problem is, not sure how to set the variable, as the key changes each time.
Or maybe there is a much better way to do this I'm not seeing?
In order for it to work your keys need to be the same. In this case you actually have a single JSON object with two properties (id1, id2). Instead what it sounds like you want are two objects:
[
{ "id": 123, "path": "/mydir1/" },
{ "id": 456, "path": "/mydir2/" }
]
Also notice that it has to be a list/array of json objects that you are passing in, not just one blob like you have. And if each object contains a path name, you should add that internal to the object itself.
But, again, notice that each object in the list/array has the same structure, just with different data. You then use the common property names in your script.
I have a Vuex.Store where I have centralized all site data, this object is actually pretty big. In different pages, the user needs to search data while the result has to be paged.
In order to show all data, I partition a particular object array in my store in a way that I keep the length and totalPages in a component, and then iterate through the original array maintained by Vuex.
However, for searching, I have created an action in my Vuex module which takes an argument and compares items within the object array against that, and it finally returns a promise.
The actual problem is that, I then create a temporary array in my component for the searched items followed by re-assigning the length and totalPages values. I feel like this temporary array is something redundant which only increases the size of the DOM and I also feel like it is such a bad idea.
The point of posting this question is to know, whether this approach would be considered as a standard solution, or whether there are better ways for searching large repositories.
Let's take for example a simple blog.
We have the following pages:
/blog/page/1
/blog/page/4
/slug-of-the-post
/slug-of-another-post
My Vuex store has the following keys:
{
posts: {},
pages: {},
}
Now when the user goes to /blog/page/1 I fetch all the data for that page from the API and store each post in the posts object, and in the pages object I store only a reference to the post.
This is how the store looks like after going to /blog/page/1
{
posts: {
'blog-post-example': {
id: 1,
title: 'test'
},
'another-blog-post-example': {
id: 2,
title: 'another title'
}
},
pages: {
1: [
'blog-post-example',
'another-blog-post-example'
]
},
}
Same happens if they go to the next page "/blog/page/2".
However, if they go back to "/blog/page/1", I can detect that the data of that page has already been fetched and I don't need to go back to the API.
This way you smoothen the UX, without loading all your blog posts into the store at once.
Hope that helps.
I have valid Datagrid defined on the page with attached ItemFileWriteStore and normally it show data.
However as soon as data will contain (almost) duplicate entry, I will see Sorry, an error occurred.
I the code I do not see any data fields definitions beyond DataGrid columns definitions.
I suppose that store and/or DataGrid components balk at duplicates, but I do not know how can I change data to avoid those duplicates.
PS my data contain 6 columns duplicates differ only by 3rd column. Is position important? Do sore/datagrid expect 1rst column to be unique? Or first defined datagrid column to be unique?
Dojo: 1.4
Did you set identifier? You need something unique (ID) to differentiate datastore items.
for example:
var store = new ItemFileReadStore({
data: {
identifier: "id",
items: [
{id: 1, name: 'A'},
{id: 2, name: 'B'},
{id: 3, name: 'c'}
]
}
});
you need to tell the store that your 3rd column is your identifier
What is the best way to rehydrate your store during app initialization, specifically the references between stores?
For instance, lets say I have 2 api calls:
/todos -> return array of todos
[{id: 1, person_id: 2}]
/persons -> return array of Persons
[{id: 2, name: 'John'}, {id: 3, name: 'Sam'}]
and a Todo object looks like this
class Todo {
...
#observable person;
...
}
Some of the Todos will have a reference to a Person, but not all of them, and not all of the Persons will be referenced, so its not as simple as just scrapping the Persons api call and just returning the Person reference with the Todos api call.
However, we can't be sure that the Persons api call will be returned first, so we cannot just assume to link up the Todo / Person reference whenever the todos response arrives (would like to run calls in parallel)...
Is it just a matter of extra logic in the client side code to ensure we set up all references whenever the data comes in? Or is there some better practice anyone has found in there experience.
EDIT
The more I think about it, I'm thinking the most predictable logic would be to always either get or create a reference object.
So in the above example, if the Todos response comes in first, we would look for the Person object with the id of 2, if it exists great, if it doesn't, create it and reference that object. Then when the persons response comes in it would do the same thing...look for Person with the id of 2, if it exists, update it with the new data, if not, create it.
Anyone have any better ideas?
The simplest way is indeed to load your objects in order, and find them. After that to load them in parallel, and find-or-create placeholders if you refer to them. It's quite a common pattern.
I'm currently designing and implementing a RESTful API in PHP.
The API allows users to search for hotels.
A simplified example of the search request is:
GET hotels/searchresults?location=<location> #collection of hotels within location
The response also contains some meta information about the returned collection.
The basic structure of the response is:
“meta": {
“totalNrOfHotels": 100,
"totalNrAvailable": 80
},
“hotels": [
{
“id": 123,
“name": "Hotel A"
},
{
“id": 135,
“name": "Hotel B"
},
...
]
This resource also supports pagination:
GET hotels/searchresults?location=<location>&offset=0&limit=20
Now, there are a few filters that can be applied to the search results, e.g. stars, rating score.
For example, if I want just 2 star hotels, I can query:
GET hotels/searchresults?location=<location>&offset=0&limit=20&stars=2
Now, in the user interface for filtering, it is common to display the number of options available per filter setting:
In my opinion, these numbers can be seen as meta data about the search query. So, we could add an extra field to the meta in the response:
“meta": {
“totalNrOfHotels": 100,
"totalNrAvailable": 80
“filterNrs": {
"stars”: {
“1": 1,
“2”: 9,
“3”: 39,
“4”: 12,
“5”: 11,
“none”: 9
}
}
},
“hotels": [
{“id": 123,
“name": "Hotel A"
},
{“id": 135,
“name": "Hotel B"
},
...
]
So, I have two questions:
Should this “filterNrs” property sit in the meta section, as proposed above? To me, it doesn’t make sense to be a separate resource/request
How can we deal with the fact that this can slow down the query? I’d prefer to make the “filterNrs” field optional. We are thinking of using a “metaFields" parameter to allow the user to specify which fields in the meta she would like to recieve. We already support this for the hotels returned, with a “fields” parameter. (Similar to: https://developers.google.com/youtube/2.0/developers_guide_protocol_partial). Alternatively, we put this field filterNrs (or the full meta info) in a separate resource, something like hotels/searchresults/meta. From a developers perspective would you prefer to have this split into multiple resources or have a single resource with the option to show full or partial meta information?
Does the number rated per star count varies? For example, do I get different "filterNrs" for the queries below?
GET hotels/searchresults?location=1
GET hotels/searchresults?location=2
I would expect such filters to be contextual, so different locations would return different numbers per star count, which indicates this is some form of contextual information related to the query.
Otherwise if the results are global this indicates it's a separate resource. If it's a separate resource scenario, you can use links to access the numbers and other details about it:
“meta": {
“totalNrOfHotels": 100,
"totalNrAvailable": 80
“filterNrs": {
"stars”: {
"options" : ["1", "2", "3", "4", "5", "none"],
"details" : "http://example.com/stars"
}
}
},