Here is the context :
on a Vue project I have a service workspaces.js that return the current Workspace for my user
I have to use this workspace from several components (header, main content, menu, etc.)
This object is binded with firestore with onSnapshot API
This object is reactive too with reactive API from Vue
On vuex I use package vuex-persist to have persistance on reload
I tried to save the current workspace in the state of vuex store, but with the different tools used (onbinding, persist, reactive) this don't work properly and data binding is not always working.
Now I want to just save the id of the workspace in vuex and get current Workspace from my service.
However to avoid multiple requests to firestore, I want to use the same object in each components that need the workspace. I have to use a kind of Singleton.
I thought about make a variable exported from the service that store the current Workspace. I wonder if this is reliable or not, I don't know how do import work exactly. Will be the same instance of my service in each component that use it ? Is there a risk that one component get the workspace and an other one get null ?
Related
For a client I am building a static website rendered with nextjs and deployed on vercel. Everything on this website is static, so I don't need any database. However, this client wants to use the instagram API to show a gallery of their photos on two of their pages. This is with a custom design, so I can't use any embed code, but to the best of my knowledge I have to use the Instagram basic display API
To the problem at hand: I was wondering if there is some way to store a single variable without creating a whole database for it in vercel. I know I can use Environment Variables, but the problem is that the instagram api needs to change the access token every 2 months. To renew the access token for instagram, I was planning to write a CRON job that runs about every month to update this value.
I was wondering if it is possible to somehow store this single value on the deployed site without creating a database just for this single value. For example, is it somehow possible to change an environment variable from within a serverless function?
Any help in the right direction is appreciated!
Thanks
You go to Vercel: settings-> environment variables -> add your variable. In this variable you can store your Instagram API variable and in the code you use process.env.{variable}
Example:
you defined name of variable as instagramAPI in your local files (next.config.js or .env.local)
module.exports = {
env:{
instagramAPI : 'https://instagramapiexample.com'
},
}
you define instagramAPI (exactly the same name of the variable as in the code) on your vercel settings
In your code (local files) you call process.env.instagramAPI variable to have the value of the string.
Your code works as expected.
!IMPORTANT! if you have some secrets or passwords in your process.env.variables you newer saves it in next.config.js. For this purpose you saves your instagramAPI to .env.local (described in point 1). More info here
I have three modules: AppModule, ModuleX, ModuleY.
In ModuleX I get and store data with NgRx but it only does so If I route to one of the components of ModuleX's and trigger OnInit lifecycle hook. I need to access that data in ModuleY.
Is there any way to do that,can I globally access to data that stored in the state from anywhere?
I'm quite new in c# and Xamarin android and I want to backup and restore my offline SQLite database created with sqliteOpenHelper Class, send and use that on another device. thanks in advance.
In Android API sets, the providers for SQLite library are available under, android.database.sqlite package. The most prominent types in the package are:
1. SQLiteOpenHelper: This is the main class that you need to inherit your classes from, in order to handle the database creation, opening or closing events. Even the events such as create new tables, or deleting the old tables and upgrading your databases to a latest version (such as upgrading the schema), are all handled here in this class-derived classes of yours.
2. SQLiteDatabase: This is the object that you get and use to either push the data to the database, or to read the data from the database.
3. SQLiteCursor: This is the cursor implementation for working with the data records that are returned after Query commands.
The way they all communicate is that, the main class for the data manipulation first of all inherits from SQLiteOpenHelperto get the functions to handle, then later has a field of type SQLiteDatabasein it to execute the functions for writing or reading the data.
For more information, you can check:
https://basicsofwebdevelopment.wordpress.com/2017/02/19/learning-sqlite-databases-in-xamarin-for-android/
https://www.c-sharpcorner.com/article/xamarin-android-develop-sqlite-database-using-sqliteopenhelper/
We're using redux and immutable objects on our redux store.
The scenario is that a user might dump the current store status into database and later the user might be able to restore it.
I'm a newbie to redux.
Is there any keywords to search for this kind of techniques?
We will try to dump the status into JSON format and reload it from database.
The key word is "persistence". There's dozens of existing libraries for persisting Redux state already - you can either try using them as-is, or look at how they work and implement some of the approaches yourself.
To actually persist the state, you'd normally either do it in a store subscription callback, or in a middleware. Then, as part of your app's setup process, retrieve the persisted state (from the server or localStorage or wherever you persisted it), and pass it as the second argument to createStore(rootReducer, preloadedState).
I have used window.localStorage for this.
const MyReducer = (state,action) => {
switch(action.type){
...
case 'SAVE_STATE':
stateString = JSON.stringify(state.toJS())
window.localStorage.setItem('applicationState', stateString)
return state
}
}
I have a MongoDB collection Foods in my Meteor app with about 8000 entries with almost 1000 fields each.
For some reason, since I included it, the response time when I call a server method from the client is very slow (seconds). For debugging, I've been removing things one by one. Now, I don't use the collection in any of the functions involved (I've even replaced the server method with just a console.log), and yet if I add the line import { Foods } from '../imports/collections.js'; to the server, the response is slow, and if I don't it is fast.
Does anyone have any idea why this could be?
Note: OP has already answered his question satisfactory. However, the following information should be pointed out, especially for those who face similar issues in context of controlling Meteor's autopublish behavior.
As long as autopublish exists in your packages list, each collection publishes to the client at the very moment, your Mongo.Collection is created.
See this code of the Mongo.Collection constructor.
Autopublish is then triggered, even just by importing your file that contains a Mongo.Collection constructor to be called (which is very likely your case).
However, you dont need to remove the autopublish package if you only want this one collection to prevent auto publishing.
Your Mongo.Collection constructor accepts as second parameter an object with options. To prevent auto publish only for this collection (while having autopublish active) you can add the following option:
{
_preventAutopublish: true,
// ... other options if desired
}
An example for your given Foods collection could be
export const Foods = new Mongo.Collection('foods', {_preventAutopublish: true});
Although the option is not documented, it works and comes in very handy when prototyping.
However, keep in mind that autopublish is not secure and should never be present in a release that is expected to be deployed on a server.
So the answer was easy.
As said in the Meteor docs,
By default, Meteor automatically publishes every document in your collection to each connected client. To turn this behavior off, remove the autopublish package
So, simply by importing the collection, Meteor interprets that you want to publish it all, and that is what was making it slow, even if I wasn't explicitly using it.