I do refactoring some vue code And find duplication like below;
- main.ts
import BootstrapVue from 'bootstrap-vuew';
Vue.use(BootstrapVue);
I know that if main.ts do 'import bootstrap-vue' then other vue file use bootstrap component without importing.
But my co-worker do this meaningless imporing on every vue component.
So i Wonder that is this duplication has any critical efficiency issue?
If yes, it related to velocity of rendering?
Imports themselves aren't a problem. A module is evaluated and included into a bundle only once. It's discarded in production build if imported values aren't used in modules that import them.
It's Vue.use that makes it different. Imported plugin won't be discarded because it's used. A plugin can do side effects that should be applied only once and should have a safeguard against multiple installation. The plugin in question has such safeguard, so this introduces no problems except several bytes of unnecessary code per module.
The necessity of this is doubtful. Vue plugins affect global application behaviour. Vue.use needs to be used only once per plugin, this is commonly done in entry point, but can be done in feature modules as well, the latter can specify their own plugin dependencies for decoupling purposes. It doesn't make sense to use Vue.use in each module where library components are used. Instead they can import components per need basis, this allows to not include the whole library, considering that there's no plugin installation anywhere in the application.
So it's either installing a plugin once or several times globally per application or feature module:
import BootstrapVue from 'bootstrap-vue';
Vue.use(BootstrapVue)
Or using a subset of library locally as many times as needed:
import { DropdownPlugin } from 'bootstrap-vue';
Vue.use(DropdownPlugin)
And/or importing all used components locally as many times as needed:
import { BDropdown, BDropdownItem, ... } from 'bootstrap-vue';
export default {
components: {
BDropdown, BDropdownItem, ...
}
}
It always depends on a library if it's supposed to be used one way or another.
Importing a library in global "main.ts" enough to use in any component throughout the application. But importing multiple times in all components can cause large size build file. So, it's better to use only one import of the library in "main.ts".
Related
I'm working on my first query module for Memgraph. I'm trying to find the best approach.
I have a query module that depends on a local submodule (firstone):
import firstone
import mgp
import importlib
#mgp.read_proc
def procedure(context...):
importlib.reload(firstone)
firstone.call()
If I get it correctly, if firstone module changes, the procedure is still using the previous code. How can I reload the Python query module during development?
You can use the use mg.load to load or reload the given module. The correct syntax is CALL mg.load("py_example");. After loading the module, all dependent Python's submodules that are imported will also be reloaded. The official documentation can be found on Memgraph site.
The getting started page says how you can directly download a core version of the bluebird library: https://cdn.jsdelivr.net/bluebird/latest/bluebird.core.min.js
However it doesn't say anywhere how to do the same with import (when using webpack) in order to avoid large build-size.
How do we do it?
TL;DR: The documented way to import d3 into es6 modules fails. What is the correct way to do this? My guess is the documentation assumes I use a workflow that resolves these problems
Details:
The readme for d3 4.x says:
D3 is written using ES2015 modules. Create a custom bundle using Rollup, Webpack, or your preferred bundler. To import D3 into an ES2015 application, either import specific symbols from specific D3 modules:
import {scaleLinear} from "d3-scale";
Or import everything into a namespace (here, d3):
import * as d3 from "d3";
Yet when I yarn add d3 and use a es6 script tag, this fails to work:
<html>
<head>
<title>D3</title>
</head>
<body>
<script type="module">
import * as d3 from "./node_modules/d3"
</script>
</body>
</html>
Failed to load module script: The server responded with a non-JavaScript MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.
Replacing the import with:
import * as d3 from "./node_modules/d3/index.js"
..gives this error:
Uncaught TypeError: Failed to resolve module specifier 'd3-array'
#jimmont is correct: importing the module form of d3 packages does not work without local building due to the "bare" imports. These can be resolved by the CDN's D3 uses, in particular unpkg.com. Here's the story.
It turns out d3 uses package.json to allow it to export two formats from a single source, npm itself. To do so, it uses the module: field.
The easiest way to access either all of d3, or a submodule/repo (there are 30 of them!) unpkg is ideal:
A dashboard to the repo: https://unpkg.com/d3/
The current umd/iife: https://unpkg.com/d3
The current collection of all modules: https://unpkg.com/d3?module
To import all of d3:
import * as d3 from 'https://unpkg.com/d3?module'
To import sub-modules:
import * as selection from 'https://unpkg.com/d3-selection?module'
es6 and es2015 modules will not work with d3 because d3 has chosen to use rollup instead. You are seeing this error because the module cannot be resolved as specified in the file "./node_modules/d3/index.js" which has lines like export {default as ascending} from "./src/ascending"; which are missing the real file name which ends with '.js'. So in other words all these entries are mis-configured to not support native modules in browsers or Nodejs.
you can either use rollup or make all the text substitutions yourself using a script or manually. I use a perl one-liner because I dislike rollup and the extra dependencies were breaking between node 8 and node 10. it is unbelievably strange that this is necessary but I also haven't been supporting a kitchen sink of module loaders.
import * as d3 from "./node_modules/d3-something/index.js"
which has content like export {default as something} from './src/thing'. because these files do not use the natively supported syntax with a full relative path (it's missing the actual file extension), it won't work without rollup or whatever making these corrections. multiple popular projects have made this same decision to require extra modules to work properly and forego native support.
see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import
I'm building a project with webpack. The project uses materializecss. When I add materialize.js to the entry file, it complains with the error below
Cannot resolve module 'hammerjs'
When I open the file, I can see the definition there but it appears webpack is unable to identify it. Same thing with weakmap in knockout-es6. My solution to this was to add a reference to hammer.min.js in resolve.alias but not sure if that is the correct thing to do.
How do I get webpack to recognize these dependencies when they are bundled together with the library in question - in this case materialize.js?
As long as you have hammerjs installed to your project (ie. npm i hammerjs --save), it should find it. As pointed out by #egunays you should also have import 'expose?Hammer!hammerjs/hammer to get access to Hammer object.
In case you are worried about possible duplication (you can verify this by examining the generated bundle), you can use webpack.optimize.DedupePlugin. webpack.optimize.CommonsChunkPlugin can come in handy as well. That will allow you to separate your app code from a vendor bundle.
See official optimization docs for more info.
It's better to use ProvidePlugin for this.
new webpack.ProvidePlugin({
$: "jquery",
jQuery: "jquery",
"Hammer": "hammerjs/hammer"
}),
This does not require an extra loader and is actually recommended in the docs:
There are cases where you want a module to export itself to the global context. Don't do this unless you really need this. (Better use the ProvidePlugin) 1
I'm currently following the Laravel Package documentation, which uses the workbench tool to create a standard package tree consisting of controller, config, views, etc. folders. Basically, most folders you would get in a standard Laravel app tree.
However, I had a couple of questions:
Why is the models folder absent here? (though the same goes for tests and commands)
Should I just create the folder myself and add it to the composer.json autoload classmap?
What classes should live inside src/<Namespace>/<PackageName>? I have noticed that a ServiceProvider is automatically created here, but I can imagine most other files just existing in the standard package directories.
Wockbench represents just a tool for creating other tools, that is triggered through CLI. Workbench is very abstract concept.
Model folder is absent simply because you don't need model in every new package. For example, if you are creating middleware package or you own filter package.
Every new class can be added to package dependent on its purpose and responsibility. It can be done in more then one way.
Classes that are general enough to go into every package are:
Package Service Provider
Facade
Basic Class
But it is not a black box. Consider for example request class - it is bound very early in the application life cycle, so no provider is needed.