So basically I have a simple vue app that is going to make requests to an API.
As there is no authentication, I need to make sure that during the vue app's life cycle (basically while the browser is open) the app will have access to some unique identifier that can be sent to the server.
In this way, the API will understand that it is the same "user" that is making requests.
As Im totally new to vue Im not really sure how I can accomplish this.
My first idea was to add code inside some global file (for example /src/App.vue) that could look like this:
if(!window.localStorage.getItem('session_id')){
let random = Array(5).fill().map(n=>(Math.random()*36|0).toString(36)).join('')
window.localStorage.setItem('session_id', random)
}
And then, when making API requests, I would attach it this way:
//pseudo code
request.header('session_id', window.localStorage.getItem('session_id')).get('endpoint1')
Is this the way to go? Or there are better ways?
Related
I hope you are fine. I want to send a get request in nuxt3 without using composition api but I don't know how to do that. I will thank anyone who give me a piece of guidance.
Thanks.
async getPosters(){
const results = await this.$axios.get('posters')
this.posters = results.data
},
Write your code as you were used too with just Options API, nothing have changed on that matter.
You can totally use Options API while using Vue3/Nuxt3. They may have some small changes but nothing too major for a simple task of querying a backend.
It looks like this is more of an issue with trying to load Axios rather than it is with the composition API. Nuxt 3 makes Axios a redundant module.
Since Fetch is the go-to considered method of requesting data in Nuxt3, have you tried changing the method of your request? It means having to load one less module for your project, and will make it a lot easier to transition between SSR and Static in the future. If not, it might be worth using the previous version of Nuxt.
Here's the documentation: https://v3.nuxtjs.org/getting-started/data-fetching in Nuxt 3.
In the app I'm working on it's a fairly big codebase and components/pages are sometimes based on user roles. Admins will be able to see certain buttons or sections while regular users are not.
I need to modify a lot of the existing pages/components to accommodate a new role that's being added, which is view-only-admin.
This role will only be able to see everything including calendars, tasks, etc. but they are not allowed to make any sort of updates.
It would be a tremendous amount of work to go through the template of each component and file and look for v-if admin and also add a view-only-admin as well as make every single button or submit/click method behave differently for a view-only-admin role.
What would be the best way to handle this for the entire app? Re-writing and modifying v-if and submit methods seem like a bad use of time.
I've only been working with Vue/Nuxt for a few months, but I have read Mixins are pieces of code that you can reuse.
Would it be possible to write a mixin so that if the role is "view-only-admin" and there's an action that is a put/Post call, then they are not able to perform those API calls and presented with an error message?
I'm not sure how to go about properly implementing this feature. If I am able to stop all PUT/POST calls using a mixin, it would just redirect to a 404 right?
Thoughts?
If you are using axios for POST/PUT methods, then you should definitely check Interceptors.
But if you add only an interceptors without UI updates - your users may be confused why some buttons exist but doesn't work as expected.
I'm building a simple app where that shows product recommendations.
I want to make it possible for the client to choose how many products he'd like to display, like from 5 or 20 with a liquid variable called {{NofProducts}}
I'm using the shopify app example, there are two important pages:
pages/index.js <- here the client can write inputs
theme-app-extension/block.liquid <- here we write a liquid code that will be appended to the page.
How do I pass the inputs from index.js to the block.liquid?
Do I have to store it elsewhere in a database for each user?
Do I have to create a file using graphQL inside each theme with the user choices using "createScriptTag"?
Ok, unfortunately every Shopify tutorial is extremely confusing for beginners.
They way you pass the store owner inputs to the app is using a database, I did it using Redis, but you can use MongoDB or maybe even a local file, but that's not ideal.
You should not store the user inputs inside their theme, because each time you access or modify a file in the customer's store, you need to use their getSessionToken function and make a new request using the token, while using your database you just need to get the session ID using SESSION_STORAGE.
We plan to create a Shopify app but we face some problems to find in documentations how to interact with pages.
I`m not sure we must ask every time users to add codes and etc, so I need to know if I miss something.
I need to interact with the product pages in Shopify from an app.
I search and read all the web for this and everything is how to start but not the actual examples.
I know for the ScriptTags and how to include them but that is.
If someone can give me a simple example of how for example to hide the Buy button and insert something on instead.
I know how to select it with the default theme with JQuery but what about all other themes?
There are two ways to interact with the front page:
1) Inject some code in the page ( the live one )
2) Use ScriptTag as you mentioned.
The code injection script will modify the product template for example and inject your code if you like to do this automatically or you can instruct the user to do so on their own, but if they are not code savvy there might be issues.
In addition this code will live only on the live theme in most cases. And if the user likes to delete your app at a specific time you must be sure to write the logic in such way that it won't affect the site if your app is no longer present ( since it will be really hard to clean up the files once you add the code automatically )
For this approach you will need to use the Asset API.
You will need to get the content of the file with a GET request to the file and make a put request in order to update it.
The better approach is to use ScriptTag API.
This will allow the use of a script file that will be attached on EVERY theme. This will not modify the theme files in any form or shape.
It seems that this is the approach that you are looking for.
Please have in mind that you will be the one hosting the file from your app so pretty much you can write what ever you like there. So if you like to use jQuery you must be sure that the themes have included jQuery or you will have to add the jQuery core code inside your script.
As for how to write a script tag, there is a pretty straightforward documentation here: https://help.shopify.com/en/api/reference/online-store/scripttag#create-2020-01
im building a specific book reader like app.
Main page call api/booksList and receive the json array containing each book info like:
[ { id: server_db_id, title: "title test", sum: 10 , date: ... }
]
ans its cached after the request, so im not saving the book list into indexedDB, localStorage or other storage. If i need one specific book, i just call the api book list again and filter it. Is that bad design? (book will be over 200 items)
Whe user open the book, it call the /api/book/book_id and its cached too, the opened book response is a json list of the lines of the book, eg:
[
{
id: ...
content: "This is line...lore ipsum..."
....
}
]
I put the api response inside vue data variable and the component is rendered correclty
Im not using any kind of handler for keeping this offline by my hand. To detect if user already opened this book, i just call the api, check if errors happened or the responde body has content.
Is that a wrong, bad or stupid decision? Will this hit the quota limit api or other kind of limitation? The "gods" of pwa will raise the finger to me and say: WAAAT. (im not using indexedDB at first because it need some models handling and i want to make things easier if possible)
I my self was just researching this and concluded, at the moment I am going to go with this method, where I use cache for assets, js, css, html etc based on their matching routes.
Then when it comes to data e.g. json requests etc. Its best to store them in indexedDB (or an equivalent), which really does not require a model or schema as such.
See Jake Archibald's IndexedDB-Promise library https://github.com/jakearchibald/idb its really simple to get your head round.
Though both Jake and Addy say it's not a defacto rule, so you can decide ultimately what is best for you.
Read this for better clarification
https://developers.google.com/web/ilt/pwa/live-data-in-the-service-worker
https://medium.com/dev-channel/offline-storage-for-progressive-web-apps-70d52695513c
It helped me to make a better decision on how to go about moving forward.
Recommendations Also
Check out PWA Training: https://developers.google.com/web/ilt/pwa
Workbox: https://developers.google.com/web/tools/workbox (This has sped up my development massively!)
Codelabs: https://codelabs.developers.google.com/ (Search PWA)
The guides on here are really good at taking you through everything you need.
Good Luck with your PWA
Random thought (edit)
One thing that makes me question this though is based on some of the examples and guides I have seen is that, data storage is handled in a more ad-hoc manner. For example, if the PWA calls out an API, there are two methods I have come across where you can either manage cached data in the application or in the service worker, e.g. if your API calls to get JSON fails in the app, it can revert to getting data in the indexedDB which hopefully was pre-cached the first time your app called the API.
Or you can use self.addEventListener('fetch', (event) => { ad-hoc stuff here }) this is where you can match either an asset, or data request and hijack the response with either a cache or indexedDB response. Which prevents the need handle offline data in your app.
The first method makes me feel uneasy so i'm gonna go with the addEventListener approach both in the service worker cause thats what it is there for plus my app does not then have to worry about that.