How can I re-use the admin react-day-picker.js component (already included in keystonejs) on a front-end form date field?
react-day-picker is installed as a Node module by Keystone. You can require/import it to re-use the code within that folder. You can alternatively save it as a depdency in your own project to make sure you always have it, though it isn't necessary since Keystone has it in its own package.json.
import DayPicker from "react-day-picker";
import "react-day-picker/lib/style.css"
https://www.npmjs.com/package/react-day-picker
Related
I am trying to add a paintworklet to my application, but I am having a really hard time.
The worklet is a npm dependency, but worklets can't be inlined, they need to be registered like so:
CSS.paintWorklet.addModule('url/to/module.js');
I am having a hard time, because even though that currently works in my application, I am not sure if this is the right way to go about it, or if it will work in production. Currently, my url points to a file inside node_modules and I am not sure if nuxt will do anything with this.
I am currently doing this with a .client.js file inside the plugins folder. But they need an export default function(), but the worklet code does not have an export.
What I am currently trying to do, is tell nuxt somehow to grab certain files from node_modules and serve them as assets somehow, and then reference them some other way. But I cannot find any resources on this.
Any ideas would be appreciated.
If the file path is specified in a literal string, containing node_modules, the paint worklet might appear to work in development mode, but the worklet file will not be bundled in the build output:
CSS.paintWorklet.addModule('./node_modules/extra-scalloped-border/worklet.js')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
❌ file not bundled in build output
Solution: Import the file
Importing a file enables the bundler to track the file, and include it in the build output. Nuxt 3 uses Vite by default, and the Vite docs describe how to import the file to use with paint worklets:
Explicit URL Imports
Assets that are not included in the internal list or in assetsInclude, can be explicitly imported as an URL using the ?url suffix. This is useful, for example, to import Houdini Paint Worklets.
import workletURL from 'extra-scalloped-border/worklet.js?url'
CSS.paintWorklet.addModule(workletURL)
Since the CSS.paintWorklet API is only available in the browser, make sure to use this in the mounted() hook, which only occurs client-side:
import workletURL from 'extra-scalloped-border/worklet.js?url'
export default {
mounted() {
CSS.paintWorklet.addModule(workletURL)
}
}
demo
I'm creating a Bootstrap Vue application (built with Vue CLI), and there's a Javascript library I want to be able to utilize: https://nadchif.github.io/html-duration-picker.js/. I tried putting the file in /assets and then using import in the script portion of App.vue (import './assets/html-duration-picker.min'), but I have not been able to get the script to work, not sure why (nothing happens, no duration picker shows). As an alternative, I thought I could maybe simply load the library in the traditional way in the head of index.html. But I'm not clear what the src URL should be for a file in the assets directory. Or should it be in the assets/public directory?
Honestly, you might as well use the npm package, if you are using Vue CLI, to save yourself a lot of trouble:
npm i html-duration-picker
DOCUMENTATION.md is where the installation instructions lie. While there aren't any for Vue, there are instructions for Angular, and it's fairly easy to get it working for Vue.
Just import html-duration-picker:
import * as HtmlDurationPicker from "html-duration-picker";
...and initalize it in mounted():
mounted() { HtmlDurationPicker.init() }
You can also run HtmlDurationPicker.refresh(); to "update dynamically loaded input boxes." I don't think this is necessary if you use v-model to bind the boxes' values to data properties which update fine from either end.
Here's a sandbox you can check out for more info.
If you do want to import it manually from assets, though, then what you're doing is probably fine (though you might need to add the .js to then end of the path); you'll just have to initialize it.
I would like to use this component in my Vue app: https://commbocc.github.io/hcflgov-vue-esri-search/docs/
However it is throwing an error: TypeError: "t.$store is undefined"
I suspect the cause is that I am not using VueX, so I'm failing to initialise a VueX store that the component is looking for.
In general, is it possible to use a component that uses VueX if my app does not? Is there some way around this? I think the effort involved in incorporating VueX would be too high.
Yes you can. In most cases, people create vue-plugins. When doing that, you can install them like npm install myCoolPlugin and use them in your app by importing it: import myCoolPlugin from 'myCoolPlugin' and then depending of the plugin, you can either globally install it like vuex does:
Vue.use(myCoolPlugin)
or you can explicitly use the plugin's components as you wish directly where you are going to use them like so:
import {coolButton, coolInput} from 'myCoolPlugin';
export default {
name: 'home-page',
components: [coolButton, coolInput],
...
}
Plugins also have a package.json file that holds metadata about what that plugin depends on etc (just like your app). When you npm i myCoolPlugin, npm checks the plugin's package.json file to see what 3rd party packages the plugin depends on and then continues to install them in your app's node_modules.
The issue with your component "esri-search" is that it is not set up as a package/plugin. Therefore it will not install any dependencies it needs (like vuex, lodash etc...) in your app.
This is why you had to install vuex as a dependency to your app, because when you copy paste this component in to your app, it is not a plugin, it becomes your app.
Does this make sense? :)
It seems in this case I was able to solve that error like this:
npm install --save vuex
In main.js:
import VueX from 'vuex';
Vue.use(VueX);
This doesn't fully answer whether or not this would always be the case though, so open to better answers.
I created a small vue.js library that is using scss for styling and published that as npm package. It works well with a default theme included into the package. But what if I would like to provide a custom theme from the application that consumes that npm package, how would you do that?
The source for a very basic version of the library is here: https://github.com/gwildu/gwi-vue-components
The idea is, that you would copy paste the styling folder somewhere (e.g., into your application directory or into another npm package) and configure the library package to import from that copyied directory.
I did some investigation myself and found that there is a big discussion about having dynamic imports in sass since years. This issue (open since 2013) claims to add such a feature (they call it load). Not sure, how actively sass is still developed and when this feature will be supported. For now I see 3 possible solutions:
move to LESS as it supports dynamic imports. Semantic UI gives you a hint about how theming could be done in LESS
It is possible to import from relative paths in SASS. That way you are also able to import from a parent directory of your package root directory (your application directory) like, e.g., #import '../../theme/index';. You would support somewhere in your package an example of a theme that the consumer then would have to copy to, e.g., the root directory of his application and adjust it to his needs. In your package you would then import the theme from that directory in the consumers application folder. The downside is, that the package would not work out of the box
You have a default theme in your package and you add some instructions into the readme how the user can override that theme in a build script. The consumer would have to copy the default theme to his application directory, adjust it to his needs and in the build script he would replace the theme in, e.g., node_modules/your-library-package-folder/theme/ by the theme in your application folder.
To be complete here is the approach with a dynamic import (that is not yet supported by SASS):
In your main theme file in the library package (that would be imported by the components) you would do a relative import of kind of a config file from the consumers application folder like in approach 2 (see above) but that config file yould not contain the theme but only the import path of the theme in a variable. that variable then would be used by the package main theme file to import the theme. For making the library work out of the box, I guess there would be a way to have a default theme as backup if the config file in the consumers directory would not exist (not tested)
Update:
I tried approach 3 but failed to get something useful. The issue with that approach is that you would have to somehow sync your custome theme with the default theme when you update the library to a higher version which might get too complex to handle in a reasonable way. Then I tried to use the overwrite feature of SASS as described here: How to overwrite SCSS variables when compiling to CSS which led me to approach
In your library component you first import a file with possible custom variables and you declare your variables in the library as default.
The issue with that approach is that SASS does not support optional imports. The file with the custom variables have to exist somewhere. So if the library updates you again have to sync your custom theme files for each component / file that was changed in the library. Apparently SASS also don't want to support such a feature in the future: https://github.com/sass/sass/issues/779 which is sad, as it seems to me an essential feature for being able to do theming without a highly complex build step.
Overall, it seems SASS itself is making every effort to prevent a simple theming approach which makes me think of moving back to LESS again. Not having a simple way for static theming in SASS in my opinion outweight the cons of not having an easy way to define custom functions in LESS.
I am trying to create a plugin that utilizes components from another Vuejs plugin (Vuetify). Basically, I have some common components I want to share across multiple applications with our company.
I thought it would just be a matter of:
Create a github repo for the shared components
Author the plugin
Reference the repo in consuming apps via npm install
Here is the gist of the plugin:
// src/index.js <-- package.json/main is set to "src"
import MyComponent from "./MyComponent.vue";
import * as api from "./api";
export default function install(Vue) {
Vue.component("myComponent", MyComponent );
Vue.prototype.$myApi = api;
}
At the moment, the behavior I'm seeing is:
GOOD
plugin install function is being executed
functions from api attached to Vue.prototype are available in app components
my-component is available in the app and renders markup
BAD
$myApi and Vuetify components are not available in an application instance of of my-component
If I copy the same files into the app and change my import, all works as expected. So, I now wonder if I'm missing something regarding sharing code via external modules.
I've tried these alternatives with the same issue:
use npm link to link the plugin module to the app
manually, use mklink (Windows sym link) to link plugin module to node_modules in the app folder
use a long relative path reference to the plugin module: import MyPlugin from "../../../my-plugin"
I've put this issue off for a while, but for anyone wondering, the issue is with using Single File Components and webpack not compiling those in external modules.
The 2 options I have are:
Don't use Single File Components. I.e.: Just use .js instead of .vue. I've seen some libs like Vuetify.js take this approach
Compile the .vue files in the library module and include them in the source such as ./dist folder.