I'm used to use this WebSQL wrapper: https://github.com/psayre23/WebSQL
I want to use this in my Vue project, but I can't get it working. I did the following:
import * as WebSQL from './WebSQL';
var db = WebSQL('test');
Object.defineProperty(Vue.prototype, '$db', { value: db });
also tried:
require('./WebSQL');
var db = WebSQL('test');
Object.defineProperty(Vue.prototype, '$db', { value: db });
But I keep getting:
Can't find variable: WebSQL (WebSQL.js:429)
The repo you have provided is out-of-date. Last update was 5 years ago.
The library is not compatible with webpack.
E.g. this will not work
import * as WebSQL from './WebSQL';
It relies on global availability of WebSQL which is deprecated. As #Ohgodwhy noticed, use IndexedDB instead. If you'd prefer a simple API, try libraries such as localForage, dexie.js, ZangoDB and JsStore that make IndexedDB more programmer-friendly.
Related
We have a vuejs 2 project.
We needed some function of dayjs.
We abstracted the dayjs into a single utility file and following the guide ended up with this:
import { i18n } from '#/plugins/i18n';
import dayjs from 'dayjs';
import calendar from 'dayjs/plugin/calendar';
dayjs.extend(calendar);
export default async (date: Date, locale?: string): Promise<string> => {
import(`dayjs\locales\${locale}`)
const time:any = i18n.t('datetime.dict');
return dayjs(date).locale(userLocale).calendar(null, {
lastDay: `[${time.yesterday} ${time.at}] LT`,
sameDay: `[${time.today} ${time.at}] LT`,
nextDay: `[${time.tomorrow} ${time.at}] LT`,
lastWeek: `[${time.last}] dddd [${time.at}] LT`,
nextWeek: `dddd [${time.at}] LT`,
sameElse: 'LLLL'
});
};
The app works perfectly fine, but vuejs is outputting every single langauge file from dayjs as a chunk and also adding the prefetch script tag to the index.html.
Has anyone else hit this issue and is the above code snippet wrong or should there be a more precise import?
Here is a screenshot of only some of the dayjs chunks.. each is completely the same with different langauge strings in... but we didn't even import the locale setting options yet.
#MichalLevý gave the direction to the answer to this issue.
Essentially, webpack cannot know which single file to import when you say:
import(`dayjs\locales\${locale}`)
So.. it just creates a js chunk for every single file it finds. Which is not overly bad on its own.
When you combine this behaviour with vue-cli's default prefetch behaviour, this is when things get bad... the result is that every single chunk that webpack creates ends up being a "pre-fetched" line in the HTML head in the outputted index HTML file.
So when there is 400 chunks from a dynamic import (in this case locales from dayjs) then there is a prefetch for all of them.
It depends on your setup but.. for us, the app is also a PWA so there is effectively no requirement for prefetching as the PWA will also download... in fact it doubles the downloads.
The answer for us was to be more specific on the prefetch:
https://cli.vuejs.org/guide/html-and-static-assets.html#prefetch
And also, as we only needed a few languages, import only what was needed but being specific and not passing a variable to map to a path
Recently, I am trying to make a web page using express, and I am trying to manage login session information and bulletin board data through lowdb.
But when I try to generate and run the code that requires lowdb and controls lowdb,
There is a error with the require syntax with the err_code 'ERR_REQUIRE_ESM'.
When I googled it, it said that it was a syntax compatibility problem between commonjs and ESM, so do I have to convert all other codes to ESM because of one lowdb?
The code below is the code I made to control lowdb.
var low = require('lowdb');
var FileSync = require('lowdb/adapters/FileSync');
var adapter = new FileSync('db.json');
var db = low(adapter);
db.defaults({users:[], topics:[]}).write();
module.exports = db;
I don't want to convert the whole code to ESM because of lowdb, I want to use lowdb through commonjs. Or is there any other good way to handle local db via json file like lowdb?
Use lowdb#1.0.0 and it will work.
npm i lowdb#1.0.0
I have an npm library which imports Angular FullCalendar v5 and everything works fine there. When i try to import my project library to another project and try access the full calendar frontend I got a warning and a message error in my browser console:
- Warning: main.js:7358 Unknown option 'default'
- Error: core.mjs:6476 ERROR TypeError: Language ID should be string or object.
at new DateTimeFormat (<anonymous>)
at buildNativeFormattingFunc (main.js:1218)
at NativeFormatter.buildFormattingFunc (main.js:1211)
at NativeFormatter.buildFormattingFunc (main.js:1009)
at NativeFormatter.format (main.js:1154)
at NativeFormatter.formatRange (main.js:1169)
at DateEnv.formatRange (main.js:3984)
at CalendarDataManager.buildTitle (main.js:6909)
at CalendarDataManager.buildTitle (main.js:1009)
at CalendarDataManager.updateData (main.js:7113)
I can't figure it out why but i know it's in this line of code at main.js (#fullcalendar/common/main.js)
Line 1218 -> var normalFormat = new Intl.DateTimeFormat(context.locale.codes, standardDateProps); The error is that the variable context.locale.codes is undefined.
Can anyone help?
I've just had the same error. Not that I was importing a project library of my own but I was importing the Fullcalendar library (from node_modules). I had enabled localization using the locale property of the calendar options but I always got this error Language ID should be string or object.
Two things was wrong:
I was importing the locale code incorrectly which resulted in this error. The current version of Fullcalendar (6.0.0) has all its locale code under #fullcalendar/core/locales.
I was using dynamic import like this: import("#fullcalendar/core/locales/da") and it worked fine but I had to access the default property of the exported object. Using async/await syntax it becomes:
const localeModule = await import("#fullcalendar/core/locales/da");
const calendar = new Calendar(someElement, {
(...),
locale: localeModule.default
});
Not directly answering your question but it sounds like you're using locale, too, and your other project is importing your project library in a way that makes the default property of the module containing the locale code undefined.
I am trying to create a new app in vue.js. Basically just wanting the same output from cybersource microform node.
https://github.com/CyberSource/cybersource-flex-samples-node
In my vue project main.js
import cybersourceRestApi from '../node_modules/cybersource-rest-client';
var instance = new cybersourceRestApi.KeyGenerationApi(configObj);
I am encountering an error with its dependencies. There's a lot missing but here's first 3 examples
ApiClient in ./node_modules/cybersource-rest-client/src/index.js
api/CaptureApi in ./node_modules/cybersource-rest-client/src/index.js
api/ConversionDetailsApi in ./node_modules/cybersource-rest-client/src/index.js
Error
I have been trying to use publicRuntimeConfig / privateRuntimeConfig
On nuxt 2.4.1, I have defined my runtime config as follows on nuxt.config.js
publicRuntimeConfig: {
DATA_API_HOST_URL: process.env.VUE_APP_DATA_API_HOST_URL,
},
privateRuntimeConfig: {
AUTH_APP_CLIENT_SECRET: process.env.VUE_APP_AUTH_APP_CLIENT_SECRET,
},
and calling it as follows on my login.vue
asyncData( ctx ) {
console.log(ctx.$config.DATA_API_HOST_URL)
//some activity
}
The keys are showing up on $config inside asyncData. I debugged on chrome dev tools. But value is not read from process.env.VUE_APP_DATA_API_HOST_URL. The value is showing up as undefined. However, process.env.VUE_APP_DATA_API_HOST_URL is showing the value OK. The whole point is to move away from process.env.
this.$config.DATA_API_HOST_URL also does not access the values.
'${DATA_API_HOST_URL}' is shown in examples but I believe it is only for explicit param declarations at asyncData like asyncData( { $config : {DATA_API_HOST_URL}).
When I pass values as it is using DATA_API_HOST_URL: process.env.VUE_APP_DATA_API_HOST_URL || 'https://test.api.com', it seems to copy the value fine using ctx.$config.DATA_API_HOST_URL!
Looking to me like copying process.env to *RuntimeConfig has a problem!
What is the recommended way of importing and using runtime configurations?
As per documentation in the Nuxt blog post you marked, the feature your are trying to use is released in 2.13 (you´re using 2.4 if i not misunderstood). That could be the reason behind the behaviour you're seeing.
I'd recommend update your project dependencies or trying another approach.
I think you should use Docker to set dynamic runtime config like link below:
https://dev.to/frontendfoxes/dockerise-your-nuxt-ssr-app-like-a-boss-a-true-vue-vixens-story-4mm6