My idea is to reduce the number of requests to the server from the web client. Say, a view/component that shows user data (first retrieved before this view/component is rendered), if the user reloads the page (F5) then the whole application is reloaded and initialized again, so another request to the server to get that data again, is there any way to maintain or "caching" that state locally?.
I don't know how to implement this.
you can try redux presist link : https://github.com/rt2zz/redux-persist
or you can use localstorage : https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
Like others have said, local storage is probably your best bet, but I don't think it's a very good idea. If the users reloads the page, that's essentially a blank slate for your app. You could get the data from local storage but how do you know it's still up to date? You'd need to check with the server anyway.
You should definitely look into a redux/store solution where you can store data for use while the user is using your app, so you can share data between components and don't have to fetch the same data every time. But actually storing it locally just reeks of bad practice, IMO.
Related
So I'm working on a react application as a front and as the back python, Django and rest.
I'll do the front part in a few days, but a question spawn: how can I manage all my apps for the user with an account and the other (without the account)?
I look a few options but I don't really know which one is better:
local storage
context API
cookies
For example if the user is connected and wants to see him own profile page, he could without fetch in the code cause it's just a few information like name, email, ...
I don't know if it's enough to clear but hopefully enough to get some suggestions.
Cookies are mainly for reading server-side, whereas local storage can only be read by the client-side.
An other point is saving data, a big technical difference is the size of data you can store, localStorage give you more space.
Context API you'll use it eather you work with cookies or localStorage
You can call the API for fetching information the first time the user logs in, and then you could store the information on the app state for the whole session. If you want to store information between sessions localstorage works just fine, is easy to access. However, you'll have to check if this information exists when the user logs in.
Context API can help you to access the stored data easily by using useContext react hook API in other child components and manage them by React, but localStorage is a way to persists Context API changes with localStorage to get them back after every page reloads(prevent losing data in page refresh). But cookies have a maximum length(I don't know how much is it) which isn't the best way because it has security issues and a use-case of cookies is using them on the server-side by the backend.
After logging into an app (React.js), I am caching the member data in localStorage as a lot of my components are using it and request only needs to be done upon log-in, ideally.
However, a few properties in this member object may be changed in the backend manually so the frontend doesn't have a way to know whether the member object has changed at all. (Again, ideally, any change to the member object should go through some form submission that directly changes the DB, with which an update can be triggered for the localStorage, but this is not an option at this time.)
Example scenario: There's a generic form in the app to request for additional credits. Customer service will receive an email regarding the request. Credits would be manually updated for Customer A (in DB). If Customer A doesn't re-login (where the get request for member is done), localStorage will still show the old no. of credits.
If this is the situation, what's the best way to go about it?
Don't store member data in localStorage at all so as to keep the data fresh. Just call the endpoint whenever it's needed.
Use sessionStorage instead?
Trigger a refetch when the user refreshes the page / app (although user may not know that they need to do this to update the data).
Suggestions?
Calling the endpoint whenever its needed is ideal if the data is going to change based on things outside of the user's control.
Session Storage is just local storage that gets wiped when the browsing session ends, you'll still have the exact same issue
This doesn't really solve the problem, and it's typically a bad user experience to require the user to perform regular maintenance tasks in order to use your application to the best of its ability
I'd go with just getting the data fresh.
At a high level, you have two choices:
Poll (periodically call the back end to refresh the data)
Open a persistent connection (like a web socket) to the server, and have the server push updates to clients.
The latter option would require a lot of changes, and it changes the scalability of your app, so the former choice seems like the most reasonable option for you.
It's smart to keep using localStorage so you have an offline copy of the data and aren't blocking rendering during page load; you can have a background periodic refresh process that doesn't disrupt the user in the meantime. If your data is mirrored in something like redux or context, then your UI could seemlessly update if/when the data changes.
If you do not know when member has been updated, don't store it. You should query the back end every time you need member. That is the only way to keep the data sync with your database.
I have a 40-50MB JSON object that I need to persist across to a different page.
This only needs to happen once (one transition) but I'm still way over HTML5 LocalStorage limits, what other options do I have?
Unfortunately, that is too much data to store for most browsers. Even combining sessionStorage and localStorage both will not get us even close.
There are a few options you can try though:
You can store the data on your own server. This will depend on what web server/environment you are using.
You can use someone else's server to store the data. For example, you could use Google Drive's API. This does mean that your user needs a google account. You could also pay for a service like Amazon S3 to store it.
You could create a 'container' page, which loads and displays the pages, but keeps the session going. How exactly this works depends again on your environment.
40-50m is too huge for a browser, the worse part is if mobile is involved, what you can do is split the data into chunks, keep some in sessionStorage, localStorage and the remaining on your server, so that the part on the server will be fast enough to load, You will have to join them once all is loaded and done. I wouldn't recommend this method though.
I'm developing a social app using Vue.js and Vuex store to keep app's relevant variables around.
Now I'm wondering if there are any best practices as to which parameters are better to be kept in browsers's localStorage?
Currently I keep token in localStorage, but wondering whether I should also keep username and other pertinent user data in localStorage, in order to preserve them from being perished on page refresh?
There's no correct answer here; just some thoughts:
Unless you have a good reason to, I wouldn't store the username in local storage. What advantage would you have by dong so? If the user logged in to their account from a different browser and changed their username, that would invalidate the username stored in local storage on other browsers. Most users expect that reloading the page should completely refresh all the data. People will think your site is broken if they reload the page and the username didn't update. The less stuff you store in local storage, the less you need to worry about the data becoming stale.
At a minimum, you should definitely store authentication token in local storage. From that, you can make requests to the server on page load to obtain all other data including the user itself.
I do not think that you need to store anything in local storage at all. If you have some authentication setup, you could store just your token in a session cookie and retrieve all needed data from the server.
Trying to keep the saved data on the client to a minimum is a good idea. Just keep the token in cookie, retrieve username (and so on) from the server when first loading the page. The retrieved data can be stored in some javascript vars. These values get only cleared on a page reload and then you have to retrieve them once from the server.
Reloads should not occur often or not at all, when you have a single page app.
I am currently working on a mobile app..where I am fetching a response from a REST GET call.
Every thing is perfect. But , I want expert suggestion on how to re-render this data if user reloads the page.. or what is the best way to handle this scenario. Caching / storage won't help me here as this is sensitive data.
Need expert opinion please?
Maybe you should consider session storage. It will persist only as long as the current session is active (until tab or window is closed), and you can certainly think of additional security strategies, such as encryption and expiration.
Build an AngularJS service for your data source which will first query the session storage as a cache, before bothering your servers. I'd recommend creating a service that wraps session storage itself - maybe call it a ThingCache - that would be injected into the main data service.