I'm in the process of migrating to systemjs, mainly given it's support of modules which makes moving to ES6 simpler.
The systemjs CSS plugin allows for elegant imports like this:
System.import('bootstrap/css/bootstrap.css!');
But this loads asynchronously, so it's not practical for loading CSS that needs to be loaded before the rest of the server-generated page. So I have to revert to cumbersome package URLs. (which will break when versions change -- and seems to be generally quite hacky -- since JSPM is supposed to be managing these details?)
<link rel="stylesheet" href="/res/packages/github/twbs/bootstrap#3.3.5/css/bootstrap.css">
Is there a best practice? In fact, are there any useful examples of the practical use of systemjs?
You might hide the body, create a javascript module that loads your assets and show the body when the assets have loaded:
assets.js
import 'bootstrap/css/bootstrap.css!';
Then in your index.html file:
System.import('assets.js').then(function(){
//Now your styles are loaded. You may fade in/display your content.
document.querySelector('body').style.display = 'block';
}); //Add the JS extension according to your SystemJS configuration
Related
I am hoping to confer on a strategy for a flutter web app (as can ignore mobile cases here) to get chrome extension info for a Polkadot.js wallet from the Polkadot browser extension.
My first thought is to use dart's JS library and use the Polkadot extension JS package and then try and pull the info from there. However, I'm not sure how to properly use this in flutter as it is a whole package full of dependencies, not just a single JS file. Also it is in TS not JS. Any thoughts here?
Eg., I need a JS file to be able to call this; and for flutter to in turn call the JS file:
import {
web3Enable,
} from '#polkadot/extension-dapp';
By writing out a "bridging" layer, you can do it easily.
Firstly, create a normal javascript (or typescript) application (nothing related to Flutter). You should be able to happily use the polkadot lib in your js/ts code without any problem. You may need to learn a bit about how to develop js code normally (e.g. you can depend on polkadot using npm, etc).
One small thing is that, you should "expose" some object publicly in your js/ts code. For example, your code may look like window.myFancyFunction = function() { call_some_polkadot_function(); }. Of course you can do more things like exposing other functions/objects/...
Then, you can bundle this normal js/ts application into a .js file. This is still very normal for js/ts developers and should have nothing special to deal with here, and you still do not need to touch Flutter at this stage.
Next, load this single-filed .js file when you are loading your Flutter Web application. You may simply do this by editing your Flutter Web's html file and add <script src="my_single_filed_js_mentioned_above.js" />. Notice that, when loading this script, it simply sets window.myFancyFunction and does not do anything more. Still very trivial here, should have no problem.
Lastly, in your Flutter Web code, i.e. Dart code, call that window.myFancyFunction function. For example, Flutter Web : How to run javascript using dart js says you can do import 'dart:js' as js; js.context.callMethod('myFancyFunction', ['some arguments']);
OpenUI5 documentation suggests starting work by using a library loaded from CDN:
<script id="sap-ui-bootstrap"
type="text/javascript"
src="https://openui5.hana.ondemand.com/1.42.6/resources/sap-ui-core.js"
data-sap-ui-theme="sap_belize"
data-sap-ui-libs="sap.m,sap.ui.table"></script>
Unfortunately, this approach means load cascading 4 scripts on startup:
sap-ui-core.js
sap/ui/core/library.js (why ?)
sap/m/library.js
sap/ui/table/library.js
Is there way to bundle this four libraries into one script file?
Unfortunately, this approach means load cascading multiple scripts on startup:
The cascading behavior is mostly due to missing an option that tells the framework to load UI5-libraries and other modules asynchronously. In order to fix it, please add the following attribute too:
data-sap-ui-async="true" // available since 1.58.2 --> Replaces preload="async" *
data-sap-ui-preload="async" // for 1.58.1 and below
* Prerequisite: Is Your Application Ready for Asynchronous Loading?
Is there way to bundle these four libraries into one script file?
Yes; with a self-contained build (e.g. ui5 build self-contained --all ), you can reduce the size of your application as well as number of requests by bundling the required modules into a single file sap-ui-custom.js
In the above screenshot, for example, sap-ui-custom.js contains only the required modules from sap.ui.core-, sap.m-, sap.ui.table-, and sap.ui.unified-library, in addition to application related resources such as the controllers, views, etc..
See openui5-sample-app and the UI5 tooling for official documentation.
I am a newbie in angular2 and want to know the purpose of following imports we do in our angular2 app.
<script src="node_modules/es6-shim/es6-shim.min.js"></script>
<script src="node_modules/systemjs/dist/system-polyfills.js"></script>
<script src="node_modules/angular2/bundles/angular2-polyfills.js"></script>
<script src="node_modules/systemjs/dist/system.src.js"></script>
<script src="node_modules/rxjs/bundles/Rx.js"></script>
<script src="node_modules/angular2/bundles/angular2.dev.js"></script>
<script src="node_modules/angular2/bundles/http.dev.js"></script>
so my questions regarding these imports are:
what are these imports for?
does the sequence of these imports metter?
are there any other useful imports that we must be aware of?
Thanks in advance.
I don't see any imports in your code sample. Its just including the files of various libraries into web page. If you read some of them one by one:
es6-shim.min.js - adds ES6 language features to browsers (full list)
Rx.js adds Observables library (GitHub RxJS)
http.dev.js - adds angular2 $http module to make requests
So you can google each of the names and figure out for yourself if that's applicable for your project.
More on modules and actual imports in ES2015/ES6 you can read here https://ponyfoo.com/articles/es6-modules-in-depth for example.
"useful imports that we must be aware of?"
Totally depends on your needs. By I assume angular2.dev.js and http.dev.js would be a good to start.
"does the sequence of these imports matter?"
Not now, but only if you're using proper module system so that browser can load missing parts before executing the blocks that depend on them. And also the loader file (system.js/require.js) should be in the first before all the other files.
Here are the details about what you specified in your script elements:
The two first files aren't necessary if you use TypeScript and have configuted ES5 output.
angular2-polyfills.js - Contains ZoneJS (to trigger change detection - see What is the Angular2 equivalent to an AngularJS $watch?) and reflect-metadata (to set metadata on objects from decorators)
system.src.js - SystemJS, the library that manages modules. In short when you use import and export in TypeScript the corresponding compiled code relies on it.
Rx.js - RxJS, a library that provides an implementation of Reactive Programming concepts. In short, it provides an implementArion of observables and their operators. EventEmitters, HTTP rely on this.
angular2.dev.js - Angular2 core bundle
http.dev.js - HTTP support of Angular2
I'm wondering what the convention to use is when creating a component inside an addon project... If I generate a component in my addon project using ember-cli#0.2.0, the blueprint will create a js file in addon/components, a template in addon/templates/components, and a js file in app/components. The part I'm not real clear about is where templates should live for these components. If my component template requires a partial, I need to put the partial template in the app/templates directory. If it lives in the addon/templates directory, it can't be resolved. So the question is this: Is it best to put all the templates (the component template and the partials) in the app/templates directory or leave the component template in the addon/templates/components directory and the partial in the app/templates directory? The latter feels slightly disorganized and the former seems more correct only because of the behavior of the blueprint. Anyone have any insight?
Thanks in advance.
Ember-cli is under heavy development so a lot of the file structure is likely to change soon, but here on some insights on the current state of the folder structure and why it is arranged the way it is:
The app/ folder is what gets directly imported into your application. Helpers are pulled from here, which is why you have to have a file for each of your components in this folder. Additionally templates will get pulled from the main application here, and as such they will be accessible in the ways that templates are normally accessible in an ember app (render, partial, and standard resolution).
Some people choose to place all of their components code in app/, but this is a bad idea because the addon/ folder exists not only as a separation of your addons code, but as a way for it to be imported using ES6 imports. So, while you can't directly access the components under addon/components/, you can import them into your application like so:
import SomeComponent from 'some-addon/components/some-component'
This is very useful for addon consumers if they want to extend an addon to add some functionality.
Templates in addon get precompiled in the build tree, which makes addons a bit more robust (for instance if they are using a different version of htmlbars they will still be compatible with the base app). However, they are not accessible via the resolver, so you have to import them manually in your addon's components, which is why the blueprint for addon components looks like the following:
import Ember from 'ember';
import layout from '../templates/components/some-component';
export default Ember.Component.extend({
layout: layout
});
Styles for addons can either be placed in addon/styles/ or app/styles/. In addon/styles/ they are also precompiled and included in the application by default. I highly recommend including styles in app/styles because this makes them accessible using preprocessor imports in the base application:
#import some-addon/main.css
This makes them completely optional to users of the addon, without resorting to app.import and config trickery (which is good because nested addons _do not support app.import. Don't use it.)
NOTE: They are not automatically namespaced, so you should put your styles in a folder to make sure they aren't conflicting with other addons styles.
In summary:
Any addon code that does not need to be directly accessible by the base app via helpers, initializers, etc. Should live in addon/
Anything you want to be accessible by ES6 imports should live in addon/
Templates should live in addon/templates/ and be imported manually
Component stubs, initializers, and other files that should be included in the standard Ember build chain should live in app/
Styles should live in app/styles/ and should be namespaced in a folder (e.g. app/styles/some-addon/)
Don't use app.import.
anybody knows how to check if a js/css file is already included with typoscript?
Example
[Template_A.ts]
page.includeJS {
jsfile = fileadmin/Template/js/jquery-1.10.2.min.js
}
now if i got an extension with the same include e.g.
[Extension_A.ts]
page.includeJS {
jsfile = fileadmin/Template/js/jquery-1.10.2.min.js
}
Is there a way to prevent this kind of double code injection? Maybe i got another Template e.g. Template_B.ts where jquery is not included - than the Extension_A.ts has to include jquery by itself.
Kinldy
You can use the same key inside includeJS such it just gets overridden if you include the file twice.
Other than that you should put jQuery into includeJSlibs, such that it is loaded before the other JS files.
Other than that, the TS should be unique for each page. Therefore you always to make sure anyway that all resources are included in-order.
You should not include JS libs with the automatic extension TS setups. Use your documentation to tell the integrator what needs to be included and what not.
The various and independent inclusion of scripts by plugins and templates is one of the tricky points in TYPO3. As far as I know, this point cannot be managed at one single point.
There is a plugin "t3jquery" that offers to build, compress and share a common jQuery library. It also has a service to analyze other plugins for their dependencies. But this doesn't solve the problem in general, as many plugins don't check for libraries already loaded.
The most stable way is to remove all plugin's references to libraries manually in your TypoSkript. This gives you some simple additional TypoSkript lines. I use lines like these:
plugin.tx_imagecycle_pi1.file.jQueryLibrary >
plugin.tx_imagecycle_pi1.jQueryLibrary >
plugin.tx_multicontent_pi1.file.jQueryLibrary >
plugin.tx_multicontent_pi1.jQueryLibrary >
# Fluid
page.headerData.998 >
You can find the matching TypoSkript descriptors by searching for the library name in the TypoSkript browser or by greping in the plugin's source code. You will also need this if you wish to add libraries as part of content that was get by AJAX, thus separating the libs from the page content.
Here's a tut (in German): http://jweiland.net/typo3/typoscript/javascript-manuell-entfernen-oder-einbinden.html
Futher possibilities you can check:
Some plugins are written in good structure and offer to keep back their Javascript in the settings.
Some script inclusions may come rather from the static template but from a plugin, so don't forget to have a look there.