Windows 7 x64
aurelia-cli 0.23.0
syncfusion 14.4.20
jquery 3.1.1
I saw the other question regarding this but it doesn't seem to follow the bootstrap example. I believe Syncfusion should also be setup using the bootstrap example as a template but I cannot seem to get it to work.
My test project is just a new aurelia-cli project with default settings.
I am using the ejDatePicker control as an example.
aurelia.json I added
{
"name": "jsrender",
"path": "../node_modules/jsrender",
"main": "jsrender",
"deps": ["jquery"],
"exports": "$"
},
{
"name": "syncfusion",
"path": "../node_modules/syncfusion-javascript",
"main": "/Scripts/ej/web/ej.web.all.min",
"deps": ["jquery", "jsrender"],
"exports": "$",
"resources": [
"Content/ej/web/ej.widgets.core.min.css",
"Content/ej/web/bootstrap-theme/ej.theme.min.css"
]
}
app.html
<template>
<require from="syncfusion/Content/ej/web/ej.widgets.core.min.css"></require>
<require from="syncfusion/Content/ej/web/bootstrap-theme/ej.theme.min.css"></require>
<!--Container for ejDatePicker widget-->
<input id="startDate" type="text" />
</template>
app.js
export class App {
constructor(){
$("#startDate").ejDatePicker();
}
}
main.js
import 'jquery';
import 'jsrender'
import 'syncfusion'
......
I am not getting any errors but the control is not displaying. However if I remove the suncfusion config from aurelia.json then $("#startDate").ejDatePicker(); complains that ejDatePicker is not valid so to me that means that the config in aurelia.json is pulling in the correct javascript file.
I had the $("#startDate").ejDatePicker(); in the constructor instead of attached(). It is working after I made that change.
Related
I am working on a legacy project which uses RequireJs to load and resolve all the dependencies. It works fine on modern browsers, but i need to add support for IE11.
I tried to use babel 7 with #babel/preset-env with following .babelrc
{
"presets": [
["#babel/preset-env", {
"useBuiltIns": "usage",
"corejs": 3,
"targets": {
"browsers" : ["ie>=11"]
},
"modules": false
}]
],
"compact": false
}
the import statements injected by the preset as following
import "core-js/modules/es.function.name.js";
cause error "import statements can't be used outside a module". Even when I use modules: "amd", then core-js is imported as
define(["core-js/modules/es.array.filter.js", "core-js/modules/es.object.to-string.js", "core-js/modules/es.string.includes.js", "core-js/modules/es.function.name.js", "core-js/modules/es.regexp.exec.js", "core-js/modules/es.string.split.js", "core-js/modules/es.string.small.js", "core-js/modules/es.string.search.js"], function (_esArrayFilter, _esObjectToString, _esStringIncludes, _esFunctionName, _esRegexpExec, _esStringSplit, _esStringSmall, _esStringSearch) {
"use strict";
//...
});
which throws error like "define is not defined in require.js".
When using useBuiltIns: "entry", and then including core-js as
require(["core-js", ../other modules], function(corejs, ...){
}
)
in the main.js file, it fails to correctly resolve the path of the files even though I have included the path to core-js in require.config.paths.
I tried #babel/runtime and #babel/plugin-transform-runtime but no luck there.
So my question is what would be the best way to add babel and the required polyfills in my RequireJs project so that it is compatible with IE 11?
I've a outdated app that uses very older few packages those doesn't support ES Module as an example file-type package. So if you setup babel and node HTTP server with and then install file-type package then start building and running will throw error message like below:
Error [ERR_REQUIRE_ESM]: require() of ES Module E:\test\testbabel\node_modules\file-
type\index.js from E:\test\testbabel\dist\index.js not supported.
Instead change the require of E:\test\testbabel\node_modules\file-type\index.js in
E:\test\testbabel\dist\index.js to a dynamic import() which is available in all CommonJS
modules.
at Object.<anonymous> (E:\test\testbabel\dist\index.js:10:17) {
code: 'ERR_REQUIRE_ESM'
}
I tried this on a fresh project though my old project has an outdated config or so, It still throwing this error
Here are my index.js codes
import http from 'http';
import { fileTypeFromFile } from 'file-type';
const server = http.createServer((req, res) => {
res.end('Hello from the server');
}).listen(4001);
console.log('Server is up and running');
export default server;
file package.json.
{
"name": "testbabel",
"version": "1.0.0",
"description": "test babel with http or express",
"main": "index.js",
"scripts": {
"build": "babel index.js -d dist",
"start": "npm run build && node dist/index.js"
},
"author": "",
"license": "ISC",
"devDependencies": {
"#babel/cli": "^7.17.10",
"#babel/core": "^7.18.2",
"#babel/plugin-transform-modules-commonjs": "^7.18.2",
"#babel/preset-env": "^7.18.2"
},
"dependencies": {
"file-type": "^17.1.1"
}
}
I just tried to import the package and got the errors above.
attempt:
I thought a converter might help so used #babel/plugin-transform-modules-commonjs but still didn't help, and seems no effect on including that package
I'm not sure but added some tweaks on package.json like "type": "module" "type": "commonjs" didn't help at all.
what is the easiest solution for this issue and how do we fix it?
Note: I saw people were going back to the supported package instead of new one which doesn't make sense to me as a solution.
Option1(babel with mocha): Rename "index.js" to "index.mjs" and modify file-type's pacakage.json ("index.js" to "index.mjs"), then leave Babel to transpile for you.
// babel-register.js
const babel_register = require("#babel/register").default;
babel_register({
ignore: [
// Only work on Project-wide configuration
// overrides ignore can transpile packages(modules) from node_modules (https://babeljs.io/docs/en/babel-register/#ignores-node_modules-by-default)
],
});
Use babel.config instead of .babelrc
//.mocharc.js
require("./babel-register");
module.exports = {
// https://github.com/mochajs/mocha/blob/v8.4.0/example/config/.mocharc.js
ui: "bdd",
timeout: 5000,
recursive: true,
};
Option2(babel only): Using dynamic import expression
async function doSomething() {
const {fileTypeFromStream} = await import("file-type");
}
and
["#babel/preset-env", {
exclude: ["proposal-dynamic-import"]
}]
Avoiding Babel tanspile dynamic import expression
I'm trying to write a simple web component using LitElement.
When I try to use:
- #customElement('my-element')
- #property()
I'm getting error.
Support for the experimental syntax 'decorators-legacy' isn't
currently enabled.
Is this something related to babel?
import { LitElement, html } from 'lit-element';
#customElement('my-element')
class MyElement extends LitElement {
render(){
return html`
<!-- template content -->
<p>A paragraph</p>
`;
}
}
JS decorators are still a proposal but they can be enabled in Babel by using #babel/plugin-proposal-decorators. Class fields also have to be enabled in order to use the #property decorator.
Install the plugins:
$ npm i -d #babel/plugin-proposal-decorators #babel/plugin-proposal-class-properties
and add them to your .babelrc:
{
"plugins": [
["#babel/plugin-proposal-decorators", {
"legacy": true
}],
"#babel/plugin-proposal-class-properties"
]
}
Decorators are a proposal for JS but are supported in Babel (as already covered by Umbo's answer, which you should accept) and natively supported by TypeScript (which Lit targets).
To use these in TS you have to add a setting to tsconfig.json:
{
"compilerOptions": {
"experimentalDecorators": true
And then import the decorators:
import {html, css, LitElement} from 'lit';
import {customElement, property} from 'lit/decorators.js';
#customElement('my-element')
class MyElement
extends LitElement {
render(){
return html`<p>A paragraph</p>`;
}
}
You should accept the Babel answer to this question, but it should be clear that this works in Typescript too.
I usually declare all standard libraries that the application depends on in the manifest under sap.ui5/dependencies/libs.
Now what should I put in the bootstrap argument data-sap-ui-libs, the same libraries? What are the effects if I put less / more in data-sap-ui-libs? How do they differ?
PS. I couldn't find this in SAP's documentation, but please proof me wrong. :-)
The bootstrapping (data-sap-ui-libs) is done in the index.html. It only needs to contain the libs which are referenced in the index.html.
If your code looks like this:
new sap.m.Shell({
app: new sap.ui.core.ComponentContainer({
name: "my.namespace.app",
height: "100%"
})
}).placeAt("content");
Then you should require the following libs:
data-sap-ui-libs="sap.m, sap.ui.core"
If your code looks like this:
sap.ui.require([
"sap/m/Shell",
"sap/ui/core/ComponentContainer"
], function(Shell, ComponentContainer) {
new Shell({
app: new ComponentContainer({
name: "my.namespace.app",
height: "100%"
})
}).placeAt("content");
});
You don't need to require anything (but it may affect loading time of your app).
All libraries that are used in the views should be required in the manifest.json. So if you use sap.m in your app you should require it in your manifest.json, even if you've already required it in the index.html.
This is because the Component.js and the manifest.json are the default entry points for an app and the index.html ist just a wrapper for standalone apps outside of a Fiori Launchpad.
What are the effects if I put less/more in data-sap-ui-libs? How do they differ?
My recommendation is to remove data-sap-ui-libs from index.html altogether. Especially if the app is dealing with OData, it's important to retrieve the $metadata document as early as possible. See the example below:
In index.html
<head>
<script id="sap-ui-bootstrap"
src="https://ui5.sap.com/<version>/resources/sap-ui-core.js"
data-sap-ui-theme="sap_horizon"
data-sap-ui-oninit="module:sap/ui/core/ComponentSupport"
data-sap-ui-async="true"
data-sap-ui-compatversion="edge"
data-sap-ui-excludejquerycompat="true"
data-sap-ui-resourceroots='{ "demo": "./" }'
data-sap-ui-xx-waitfortheme="init"
></script><!-- No data-sap-ui-lib -->
</head>
<body id="content" class="sapUiBody">
<div style="height: 100%"
data-sap-ui-component
data-name="demo"
data-height="100%"
></div>
</body>
In manifest.json
{
"sap.app": {
"dataSources": {
"myODataSource": {
"uri": "/odata_org/V2/Northwind/Northwind.svc/",
"type": "OData",
"settings": {
"odataVersion": "2.0",
"localUri": "model/metadata.xml",
"annotations": [
"annotation0"
]
}
},
"annotation0": {
"type": "ODataAnnotation",
"uri": "annotation/annotation0.xml",
"settings": {
"localUri": "annotation/annotation0.xml"
}
}
},
"...": "..."
},
"sap.ui5": {
"dependencies": {
"minUI5Version": "1.108.4",
"libs": {
"sap.ui.core": {},
"sap.m": {},
"sap.ui.table": {},
"sap.ui.unified": {}
}
},
"models": {
"": {
"dataSource": "myODataSource",
"settings": {
"preliminaryContext": true,
"tokenHandling": false
},
"preload": true
}
},
"...": "..."
},
"...": "..."
}
Result
As you can see, the $metadata document is being fetched in parallel with the control libraries. This ensures that entities can be requested right away (e.g. in $batch) as soon as the libs are loaded. If libs were declared in data-sap-ui-libs, they'd be loading first, then the $metadata, and then the entities which creates an unnecessary bottleneck.
But even without considering OData, I noticed the page gets already a bit faster when the libs are removed from data-sap-ui-libs. In general, try different approaches and do performance measurements, in addition to documented performance guidelines, and regardless of what people say (including me).
TL;DR
Use data-sap-ui-libs only if:
The app has no Component.js at all.
Modules from libraries other than sap.ui.core are accessed before creating the component (E.g. instantiating sap.m.Shell as a shell for the ComponentContainer)
Otherwise, remove data-sap-ui-libs altogether and maintain /sap.ui5/dependencies/libs only - Especially if the app is supposed to be launched from an app container such as SAP Fiori launchpad (FLP) which skips loading index.html altogether.
See also What happens if a library preload file / library dependencies is not updated in the UI5-manifest?
I would kept them declared on the manifest.
By declaring them on your .html file under the data-sap-ui-libs, you are basically requiring those dependencies right after the UI5 lib is loaded - even before your component is loaded.
By declaring them on your manifest, you are declaring the dependencies for your own component. So, those dependencies are only loaded before the initialization of your component.
As the component should be isolated, you component should not expect to be always used in a standalone mode.
How do I enable snippet completion within JSX tags to add tag attributes:
<View style={styles.styleName}>
I am trying to make this snippet work but it only seems to work outside the tags:
"style": {
"scope": "javascript,typescript,jsx,html",
"prefix": "rs",
"body": ["style={ styles.${1} }"],
"description": "RN style"
},
(Untested) If you're not opposed to using keyboard shortcuts to insert snippets - assign keybindings may work.
VSCode added in "javascriptreact" for jsx files. (no need to install anything from the market place)
for example, if you want to write a fetch shortcut
{
"fetch": {
"scope": "javascriptreact,javascript",
"prefix": "fetch",
"body": [
"fetch('$1', {",
"\tmethod: '$2',",
"\tcredentials: 'same-origin',",
"\theaders: new Headers({",
"\t\t'X-CSRF-Token': this.state.form_token,"
"\t\t'Content-Type': 'application/json',",
"\t\t'Accept': 'application/json'",
"\t}),",
"\tbody: JSON.stringify(body)",
"\t}).then(res => res.json()).then(",
"\t(result) => {$3},",
"\t(error) => {$4}",
");"
]
}
}
After adding this to your code-snippets file the short cut is ready for use.
Addressing the original question. Snippets work in in a jsx tag