Comments (14)
This is one of the breaking changes.
@jods4 how hard it is to configure webpack not to create separate chunks but bundle them in the one with the dialog core? All those optional resources are now under resources
(dist/amd/resources
).
from dialog.
The reasoning behind the change is that those resources are not mandatory for the dialog to function.
If you don't need any of them just provide a config callback when setting up the dialog plugin - not calling use .useDefaults
nor .useStandardResources
.
If you want just some of them call .useResource
.
So if you are not using any you should not see any requests for those chunks. I suppose without any additional configs to the build they will still get generated.
from dialog.
Perfect
I tried removing the useDefaults()
, and as you suggested it removed the requests for the chunks (even though they are being generated in the dist folder). I don't think there's any overhead just letting them be generated, but it does create some unnecessary files which might clutter a project.
from dialog.
Btw, what is the correct path to be using to include just some resources, ie attachFocus
in my case?
from dialog.
I found out. What you can't learn by looking at the tests of the project :D (For those whose looking, use the local name of the resource ie useResource("attach-focus")
on the config-object for the aurelia-dialog.)
from dialog.
HOWEVER, this does not bundle it into the production build. My guess is that the bundling magic happens in the PLATFORM.moduleName("<module>")
When I try to add useResource(PLATFORM.moduleName("attach-focus"))
it fails (obviously) with Error: Can't resolve 'attach-focus'
.
Trying
useResource(PLATFORM.moduleName("aurelia-dialog/resources/attach-focus"))
resolves fine, but crashes with main.ts:61 TypeError: resources[name] is not a function
. Any tips here?
Solution
Add
.globalResources([PLATFORM.moduleName("aurelia-dialog/resources/attach-focus")])
on your FrameworkConfiguration
and it both works locally and in bundled mode.
from dialog.
The sole purpose of all the changes around the resources was to drop the usage of PLATFORM.moduleName
, inside the dialog code.
v2
breaking changes are more related to build setup rather than the API.
I can't give example for every build setup, but for aurelia-cli
RequireJS/SystemJS projects all needed to include the resources is to add "resources": ["resources/*.js"]
to the dialog configuration, in aurelia.json
, resulting in:
{
"name": "aurelia-dialog",
"path": "../node_modules/aurelia-dialog/dist/amd",
"main": "aurelia-dialog",
"resources": ["resources/*.js"]
}
from dialog.
Also the docs have been updated, but are not published to aurelia.io.
from dialog.
Makes sense to be independent of the PLATFORM-syntax, but as you see it has consequences. Not using the CLI and merely a plain and simple webpack config, this change makes it necessary to do the changes written in my above post to avoid both the default import of the chunks and explicit import of other resources.
from dialog.
Some thoughts:
-
The default webpack logic is that if you dynamically
import()
it should live in a separate chunk. The reasoning here is that if it's in the same chunk then it's already available in your browser so why not just import it statically? -
The answer to this question might be that loading (i.e. running) the module -- even if it's already downloaded and parsed -- could be expensive (not the case here, but anyway) and Webpack gives you an escape hatch with magic comments. Doing
import(/* webpackMode: "eager" */ './resources/ux-dialog')
will put the module in the same chunk as its parent. -
I understand that the goal here was to make those resources optional, so that people who don't use them don't get them.
I think the best way to do that is to put them in a different file that users import during their configuration (then it's part of their build), or not (then it's not).
Something like (user code):
import resources from "aurelia-dialog/default-resources";
dialogConfig.useResources(resources);
from dialog.
For v2
I was looking for some kind of middle ground. My first approach was 3.
But from project/build setup that turned complicated, personal opinion. First the resources got dropped from being reexported, so now you have to get them like import {UxDialog} from 'aurelia-dialog/resources/ux-dialog';
. Second, without any additional configuration/mapping that would resolve to something like node_modules/aurelia-dialog/resources/ux-dialog.js
. And the actual location would be aurelia-dialog/dist/${target_build}/resources/ux-dialog
. So in that case we would drop the mapping of aurelia-dialog
=> node_modules/aurelia-dialog/dist/${target_build}
to the consumer - decided against for v2
.
My goal forv2
is to keep the v1
API but also make any necessary changes to integrate the usage of class
ref API, dropping the usage of PLATFORM.moduleName
.
@jods4 with that said do you think we can go with /* webpackMode: "eager" */
and still be able to exclude those resources from the build if they are not used, without resorting to any black magic?
btw, thanks for the feedback!
from dialog.
If you go with webpackMode: "eager"
they will be included in your bundle, in the same chunk as the parent module.
Then users who want to drop them will have to resort to some Webpack plugin (does that count as black magic?)
Note that you can avoid mappings if you publish those modules at the root of your npm module instead of dist
.
from dialog.
@jods4 I don't see how they can be moved to the root, we do have different builds amd
/native-modules
/...
If we don't go for webpackMode: "eager"
would users who want to include the resources, in the same chunk as the parent module, also need a plugin?
What I want to understand is which case would require less work/be more simple:
- not using
webpackMode: "eager"
and configuring the build to include the resources in the same chunk when used - using
webpackMode: "eager"
and configuring the build to exclude the resources when not used
from dialog.
Right... silly me, I was in a context where I just deliver standard ES to everyone. Having mutliple distributions make things more complicated of course.
I guess merging chunks would be a plugin, too.
There are a few optimize
options that can aggressively merge chunks (e.g. based on minimum size) but they never merge something into the entry chunk (to reduce startup time).
from dialog.
Related Issues (20)
- Dialog VM hooks for keyboard (Enter/Escape) HOT 7
- Add class reference support for .viewModel HOT 4
- Plugin setting configurations not working HOT 1
- Error when building HOT 1
- AttachFocus is not the default export
- Dialog does not open when webpack bundle is built in production mode HOT 7
- Remove .rollupcache folder from npm package
- Cannot find name 'AddEventListenerOptions'. HOT 7
- Global callbacks / events every time a dialog opens / closes HOT 8
- Focus management on open / close HOT 5
- Typings fail to install HOT 1
- typings.json does not define dependency versions HOT 2
- DialogCloseError is not exposed in typings HOT 2
- Add whenConfirmed alongside whenClosed HOT 1
- Doesn't load template page in IE11 HOT 12
- null reference error on closing dialog
- Support typing the model with a generic type argument on the open method HOT 2
- dialog forces mulptiple chunks in webpack prod build HOT 1
- 404 on typings install for Aurelia metadata HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dialog.