I have gone down a path of using Angular2 but writing ES5 code, which means that the examples and guidance I find usually must be translated from answers relevant to TypeScript.
Can someone help me with an ES5 version of:
Bootstrapping the application. In TypeScript I see it done as:
import {WORKER_APP_PLATFORM, WORKER_APP_APPLICATION} from "angular2/platform/worker_app";
import {platform} from "angular2/core";
platform([WORKER_APP_PLATFORM]).application([WORKER_APP_APPLICATION]).bootstrap(myApp)
Accessing the web_workers component:
import {Component} from 'angular2/web_worker/worker';
#Component({ ... ])
I assumed the latter would be achieved by calling
ng.web_worker.worker.Component({ ... })
But that seems to not be the case: ng.web_worker is undefined.
The problem might be that I seem to not be able to include web_worker/ui.js properly. When I include it instead of bundles/angular2-all.umd.js I only get error messages about require being undefined. When I explicitly include RequireJS in my project I get a bunch of other errors.
Any help will be greatly appreciated!
Can I ask, why do you want to do it with ES5? You can easily use SystemJS and ES6 if you don't like Typescript. Typescript would be almost identical to ES6.
In case you still want to do it with ES5, you need to change the imports to require calls:
var WORKER_APP_PLATFORM = require("angular2/platform/worker_app").WORKER_APP_PLATFORM;
var WORKER_APP_APPLICATION = require("angular2/platform/worker_app").WORKER_APP_APPLICATION;
var platform = require("angular2/core").platform;
platform([WORKER_APP_PLATFORM]).application([WORKER_APP_APPLICATION]).bootstrap(myApp)
Another example:
var Component = require('angular2/web_worker/worker').Component;
You get the idea. You also don't need RequireJS... You can use SystemJS. You should import the main file like this:
System.import("main")
SystemJS will resolve all the require calls async, but in the code, the require calls look sync.
Related
When using autoimport feature of nuxt3:
is there any impact (types, performance, bundle-size, tree-shaking, etc..) of using the # alias to import something rather than no import at all?
Or its only purpose is to make imports explicit and maybe help to fix some IDE/linter/ts issues?
Example:
// plugins/vuetify.ts
import { createVuetify, VuetifyOptions } from "vuetify";
import { defineNuxtPlugin, NuxtApp, Plugin } from "#app"; // this line should be optional
export const VuetifyPlugin: Plugin = defineNuxtPlugin((nuxtApp: NuxtApp) => {
const vuetify = createVuetify();
nuxtApp.vueApp.use(vuetify);
});
export default VuetifyPlugin;
I wasn't aware of the # import, do you have a reference for that specifc one?
As you kinda guessed it, there are no direct benefits of making the imports yourself. In the same way that Nuxt does the job for you regarding ref, computed, watch etc, it will try to import most of the other common stuff.
The compiler will scan your file, see what you are using in your template + script part and make the import himself on runtime. It may not guess fully dynamic imports (usually for components based on a dynamic variable for example).
Still, it should work in the exact same way performance-wise.
For the types I know that there could be some limitations (not a full coverage), but since I don't use TS, I'm not well aware of all the details.
Regarding IDEs/code editors, most of the time they will work fine but some of them may require a bit of configuration to work perfectly (since it's implicit, you still need to tell your editor what is happening), otherwise some Linters may complain a bit.
Nuxt's auto import feature is probably based on something really similar (if not identical) to this: https://github.com/antfu/unplugin-auto-import
Hence, you can see in details how this one works to get more explanation.
I've found at least two ways to import functions in from a module like Ramda for example. There are probably a few more ways to do something very similar like const R = require('ramda');
Option 1 is to import certain functions:
import { cond, T, always, curry, compose } from 'ramda';
Option 2 is to import the whole module like:
import * as R from "ramda";
I would prefer to reference the module from which the function is being called like so:
R.T();
But if the 2nd option is used, does it bring in every Ramda function not just the ones used in a module I'm working in? Are there any impacts on actual memory use, or bandwidth use as far as what gets sent to the browser if option 2 is used?
Is it possible to somehow do this:
// invalid syntax below:
import R { cond, T, always, curry, compose } from 'ramda';
R.T();
My question is kinda related to this one, but it's a bit different
import R (ramda) into typescript .ts file
TL;DR: It does not matter.
import * as … from 'ramda';
import { … } from 'ramda';
will both by default always bring in the complete Ramda module with all its dependencies. All code inside the module would be run, and which syntax was used to reference the exported bindings doesn't matter. Whether you use named or namespaced imports comes down to preference entirely.
What can reduce the file size to download and the used memory is static analysis. After having evaluated the module, the engine can garbage-collect those bindings that are referenced from nowhere. Module namespace objects might make this slightly harder, as anyone with access to the object can access all exports. But still those objects are specified in a way (as immutable) to allow static analysis on their usage and if the only thing you're doing with them is property access with constant names, engines are expected to utilise this fact.
Any size optimisation involves guessing which parts of the module need to be evaluated and which not, and happens in your module bundler (like Rollup or WebPack). This is known as Tree Shaking, dropping parts of the code and entire dependencies when not needed (used by anything that got imported). It should be able to detect which imports you are using regardless of the import style, although it might have to bail out when are doing unusual things with the namespace object (like looping it or using dynamic property access).
To learn about the exact guesses your bundler can make, contact its documentation.
#Bergi is right in his comment, which I think should be the answer. I would also like to point out you can always try things out in Babel to see what it compiles to: click here to see what an example destructuring actually does
So basically even if you destructure just one function from the module, the whole module will be required. In the Babel example I gave, I just extracted Component from the 'react' module, but the compiled code actually just required the whole thing. :)
Adding to #Bergi, Also just for future reference if you want to shed unused functions and import only the desired function, use selective import like below
import isEmpty from 'ramda/src/isEmpty';
This way you can complement it with Webpack and get a better tree shaking. Hope it helps
I assumed at first that it simply means, load the jQuery module and initialize it in a variable called $.
But then, by using Atom with the atom-typescript, I got an error saying that it "Cannot find module 'jquery'". Even though all the code works in the browser, it looks like atom-typescript can't resolve anything looking like import x from y.
Now, looking at ES6 doc, I found out that you import a class/function from a module. The meaning is totally different, and it makes sense with for example this:
import { Component } from 'angular2/core';
But then what does it mean in the case of jQuery?
I am probably mixing different issues in the same one but any explanation would clear this confusion, so thanks a lot in advance :)
The statement import $ from jquery pretty much amounts to dependency injection. Just like one would write import React from 'react' to give oneself access to the React library within a file, so to can one write import $ from jquery. (In case it's throwing you off, the dollar sign is used because jQuery and its methods are accessed using the dollar (a.k.a. jQuery) operator.
As for the errors being thrown, that could be several things:
If you separately installed jQuery as a dependency in your package.json file as well as included a <script> tag from a jQuery CDN, this error will be thrown. If you're usage of jQuery is through NPM, then the import $ from jquery syntax is correct/necessary. If you intend to use jQuery through a CDN (as I would recommend), the import statement is unnecessary. (Since you've included that script tag in your index.html, you have access to jQuery and its library throughout the scope of your application). Do not, however, do both.
Also note that in the case of the import { Component } from 'angular2/core'; statement, something slightly different is going on. Namely, one is importing the named export Component, as per the (AMD specification. You can think of it, in this case, as importing only a part of the larger Angular2 core library when the entire library would be unnecessary.
Just to be sure, check that you have actually given yourself access to jQuery through either a CDN or by installing it as an NPM dependency.
Declaration
declare module "MyModule" {
export function Foo() {...}
export function Bar() {...}
}
I just need Foo somewhere, how should I import it ?
import * as MyModule from "MyModule";
MyModule.Foo();
or
import {Foo} from "MyModule";
Foo()
Which one is better than another ? Are there any performance implications of importing all the exports in the first way?
Some references which I read before posting questions:
https://www.exratione.com/2015/12/es6-use-of-import-property-from-module-is-not-a-great-plan/
Importing only what is necessary to your code is, of course, good practice. Say someone writes some thousand-line code importing everything, and then you try to analyze it. Do you think you would easily know which functions used in your code are imported or which is not? Obviously it is dubious and bad practice.
With regards performance, I suppose not much affected.
The import {} from ... syntax makes stubbing and spying on functions very difficult and normally requires additional libraries such as rewire.js. The caveat is tree shaking doesn't work as well. I'm inclined to keep my util modules small and maybe only include 2-3 functions per module. That way I can use the import * as ... syntax for my modules and import {} ... when possible for third party modules. Thus minimising the need for tree shaking.
If you need to use only Foo, I think it's better to import just Foo. This makes your code clearer, because by looking at that import you can tell which elements of MyModule that code is using.
It doesn't affect performance, because either way you have to read/download the whole file.
Also, it doesn't matter which option you choose when using a bundler like Rollup.js―even if you import everything from MyModule, the bundle will include only things that you actually use in your code.
In case anyone is still looking for answers, i have shared my thoughts on this.
Let say you have a JSON file and you want to import the entire module as a variable then go with import *.
If you have a module with multiple exported methods (That can be 3rd party packages), then you should go with import {} approach.
Any default export should be imported as "import any name".
About a year ago I have used Meteor, and now I want to use it again, but many things have changed.
When I follow the Blaze tutorial on Meteor.com, they add imports on top of their files:
import { Meteor } from 'meteor/meteor';
import { Template } from 'meteor/templating';
import { ReactiveDict } from 'meteor/reactive-dict';
I got the app working. But when I comment the imports out, the app keeps working like it should work. Why are these imports needed?
I am still using the regular Javascript, not ES6.
Thanks!
The import statement is used to import functions, objects or primitives that have been exported from an external module, another script, etc.
The name parameter is the name of the object that will receive the exported members. The member parameters specify individual members, while the name parameter imports all of them. name may also be a function if the module exports a single default parameter rather than a series of members. Below are examples to clarify the syntax.
Import an entire module's contents. This inserts myModule into the current scope, containing all the exported bindings from "my-module.js".
For more detail about the different ways we can use import along with their usage, please check this.
They still use the old globals for backwards compatibility. However it is recommended to use the imports so if in some future release they remove the globals your code will still work. You can read more in the appropriate section of the guide.
Ok you know import is to import an exported object from another file already.
The point that you may have missed is that MDG heard the need to stop loading everything by default, or at least to provide a mean to control what is loaded in memory and what is not.
Look for the /imports special directory.
Files in that folder are no longer loaded automatically, but only through import statement.
As for the tutorial, I guess they did not explained this functionality, and because it imports only standard functionalities which are still loaded eagerly for backward compatibility, it does not change anything removing those statements.