Our app's Rails part returns the same record either using an id or a slug:
/user/1 or /user/wojtek
The Ember part has loaded all users. If I want to load a particular record, e.g User.find(1), the record is returned from the store. But if I wanted to load it using the slug, User.find('wojtek') a new request has been made.
Maybe it is not applicable in latest Ember (we hasn't upgraded now), but is it possible for Ember to return the same record no matter what param I send? Does Ember use any internal mappings?
Related
I have a RESTful (Django) API which (amongst others) serves a resource called CourseType. CourseType has an ID but it also has a slug.
In my frontend site (built with Nuxt), the URL I'd like to use is something like:-
http://example.com/courses/<course slug>/
ie. I don't want to use the course ID in the URL.
But the course slugs are not unique in the database. So I can't just fetch the course using its slug as a lookup - I need to look it up using its ID.
What is the best way of doing this from a Nuxt point of view?
I do have access to all of the courses in the Vuex store - as they have been retrieved in a previous API call - so I could find the course slug in the store of courses and then use the ID to do the API call for that course. But is that the best way or should I be doing something else?
I'm quite new to Nuxt so this is all pretty challenging for me!
I have a table that shows a paginated result of large data. Those data are loaded at once. The client wants to have a Save All functionality where only those data that the user added/modified/deleted will passed down to the API.
The table:
Is there a way to only get the data that was added/modified/deleted by the user? I am using Vue2 with Veevalidate and my plan at first is to get only those who are dirty (from veevalidate) but there is no way to do that in Veevalidate. I am not sure now how I can achieve this.
General idea can be accepted.
Within my app there are multiple pages that display a drop down of "clients". The select options are loading via an GET call made in Axios. Every time a page is displayed it makes that get call.
I'm curious if it's better to store those clients in Vuex, and then just load them that way so I don't make a call every time? The only thing I am concerned about is when a new "client" is added the best way to tell the app it needs to make a new get call to update the data in Vuex.
There are many possible solutions to this.
You could use a cache in back-end suchlike Redis, or as you said, cache it in the front-end.
You can abstract this caching with a get function which will check a maximum threshold of cache age.
For example, you can set it to last for 15 minutes. If another request is made before it you could answer with the last obtained data, else it will request the data to the server again.
As I know that, instead of get() I can use onSapshot() for my queries and listen to the changes(additions, deletions, modifications) for that query. But when there are changes, onSnaphot() returns multiple full documents whether modified, deleted or added (a new snapshot). What I want to do is, to check if new documents have been added matching my query and show a notification to the user that there are new records available, and only when a button is clicked, they should be able to fetch and see the new records. I don't want to fetch from the firestore whole sets of documents when there are changes. I just want to know about those changes and fetch on demand. And fetch only the added ones.
How can I do that? Any ideas?
By the way, I am using react-native for my app.
P.S. - I know, I can run the query periodically and check if the id of the first item in the new query matches the first item id in the previous query, and so I can detect the added records and show my notification/button. But I am looking for a more elegant solution. I think the notification should be triggered from the backend instead of polling the backend periodically.
P.S. 2 - Using cloud functions would not seem to be a logical option since these queries will be different for each user of my app. Which would require running thousands of functions (hopefully more) on the firestore. Or would it?
Thanks!
There is no way in the Firestore API to get notified about changes to a query without actually retrieving the changed documents. But you can of course show just a notification to the user when your onSnapshot callback gets called, and then only show the actual data from those documents when the user chooses to refresh the UI.
On a second note, when you use a snapshot listener the Firestore client will only retrieve the modified documents on additional callbacks.
Say you attach a listener for a query that matches 10 documents. On the first onSnapshot callback, you will get 10 documents and will be charged for 10 document reads. Now say that one of the documents changes. When your onSnapshot callback gets invoked for this, you will see 10 documents again, but will be charged only 1 read - for the document that was changed.
If you only want to process the changes, have a look at the documentation on viewing changes between snapshots, which contains a good example of how to do this with the docChanges() method.
Let's say I have table with 2 columns:
PROJECTS, TASKS
Project can have many tasks.
And lets say that I will have up to 15 000 tasks
So imagine: I click on projects1 from the first column => I should see in the second column all the tasks that belong to this project.
Should I make an xhr via api to get data, or should I store everything in a json on front-end and filter with js?
something like this structure:
[{project_name: 'some_project', tasks[{id:1, name:'dosomething'},{},{}]}
What will be faster? And what is reccomended?
It is a bad idea to filter information in the client, it should just display the data sent by the server, because backend tools are designed to fetch and process data and are better for this purpose.