Many of the samples I have seen for angular2 have the following import statement:
import {bind} from 'angular2/di';
I am working in VS Code (with TypeScript) and it complains about not being able to find the angular2/di module.
However I do see a bind function defined in angular2/angular2.d.ts. If I change the import statement to the following, then the error goes away.
import {bind} from 'angular2/angular2';
Is the question in the title off-base and I am making some erroneous assumption?
If not, why do many samples reference one module to import the bind function from, yet I seem to be able to get it from a different module?
Most likely because you looked at versions from older alphas. Look at the angular2.ts file. Everything is exported from it. Also note that the d.ts is going to contain everything to resolve types in your IDE and at compilation time. What import does is actually importing the .js files.
Related
Basically I have a lot of widgets and services and stuff, like most people do, that I need to access throughout the app. I was wondering if have a single file with an export of every single file and then just simply importing that one file in every page/file i need to access something rather than just importing specific files that the page needs, will it slow down the app or cause any issues or increase file size, etc... or will it behave the same?
Example
login_page.dart
import '1.dart'
import '2.dart'
home_page.dart
import '2.dart'
import '3.dart'
import '9.dart'
import '10.dart'
settings_page.dart
import '1.dart'
import '2.dart'
import '9.dart'
import '10.dart'
or...
all_imports.dart:
export '1.dart'
export '2.dart'
export '3.dart'
... (up until)
export '10.dart'
in every dart file:
import 'all_imports.dart'
Using 'all_imports.dart' may cause unneeded dependencies but dart knows how to handle dependencies that called but not used.
Same implementation of 'all_imports.dart' is used by flutter team on 'material.dart'
You may wish to just make simple design but when you import 'material.dart' it brings everything to the table ('about.dart', 'app.dart', 'banner.dart') and many others.
I would advise you structure your application using 'all_import.dart' pattern
actually, it dosent make a difference, lets imagine this case
in login_page.dart
import '1.dart'
import '2.dart'
here you are being explicit about the dependencies of this module/file/widget, which means it only uses what it needs. which is better for maintenance and redablity of the modules dependanices.
the other case where you have all of your imports in one file
import 'all_imports.dart'
lets see what happens here:
Dart executes the file all_imports.dart
that file is importing every module that you have listed in that file
so the import calls happend again
which means that wont affect your software's performance if you dont have an all_imports.dart file.
actulally i find that this method(the all_imports.dart) will affect your program in a bad way if any.
why? lets say we have a module A that depends on both module B and module C , you would import them this way
moduleA.dart
import 'moduleB'
import 'moduleC'
the advantages is that the module is now explicit in its dependencies and anyone who looks at this module/file in the future will know what they are.
however
the other method where you have all of your imports in a single all_imports.dart file, will cause unneeded dependencies to be loaded for a certain module
lets have the same example above, module A depends on moduleB and moduleC and you listed them in the all_imports.dart file, it will look like this
export `moduleA'
export 'moduleB'
/// some other modules that you are exporting
and in the moduleA.dart file you import it this way
import 'all_imports.dart`
now
the module A has successfully imported moduleB and moduleC which it needs. BUT, now it has all the other dependancies that it dose not need loaded for it although it only needs moduleA and moduleB.
In my dart project projectxyz, I have a dart class declared in in myclass.dart. In main.dart, Android Studio gives two ways, both work, but I did not understand what are the pros and cons of each method:
import 'myclass.dart';
or:
import 'package:projectxyz/myclass.dart';
What is the difference in these two approaches?
That depends on how the main file itself is invoked (and where it's located).
I'll assume the main.dart library is inside the lib/ directory, because otherwise you wouldn't have the two options for importing myclass.dart.
If you invoke the main file with a file: URI, then the relative import of myclass.dart will also be imported with a file: URI. Since Dart uses the import URI to distinguish different libraries, if someone else imports myclass.dart using a package: URI, then it will be treated as two different libraries introducing different classes with the same name.
It used to be that running dart lib/main.dart would treat that as a file: URI. The Dart parser has gotten smarter about that, and now it recognizes that an entry point library in a lib/ directory should have been a package: URI, and replaces the entry point URI with package:projectxyz/main.dart.
After that, it makes no difference whether you use myclass.dart or package:projectxyz/myclass.dart.
Really, there is no difference between the two. Saying import 'myclass.dart' is high-level sugar for import 'package:projectxyz/myclass.dart';.
On the other hand, import 'myclass.dart' is easier to read and understand, and generally looks better. It also decreases confusion as to where exactly your code is being imported from, as anybody who reads this statement knows to look for the file elsewhere in your project. Because of this, you should try to use this form wherever possible.
I saw the following code snippet
val settings = configuration.underlying.as[CookieSecretSettings]("silhouette.oauth1TokenSecretProvider")
I believe configuration is of type play.api.Configuration and underlying is of typeConfig` (https://www.playframework.com/documentation/2.6.x/api/scala/index.html#play.api.Configuration)
I copied the code in my Apploader (as I am using Compile Time Injection). The BuiltInComponentsFromContext has a configuration variable. I thought to use that as follows val config = configuration.underlying.as[CookieAuthenticatorSettings]("silhouette.authenticator") but the compiler cannot resolve as. What am I doing wrong?
The Config library seem to have asInstanceOf instead of as but I get other errors if I use that. I notice that the code for which as works uses play version 2.4.2 while I am using 2.6.12.
I realize this is an old question, but I stumbled upon this exact problem today and couldn't find anything helpful.
The as method is provided by a third-party library (Ficus) to read case classes and Scala types from Typesafe config. You need to include it in your build dependencies, then add to imports:
import net.ceedubs.ficus.Ficus._
import net.ceedubs.ficus.readers.ArbitraryTypeReader._
Yes, I read dart import and part of directives in same file
I have this structure:
lib/
src/
one/
SomeClass.dart
one.dart
mylib.dart
main.dart
I'm trying to achieve this behavior:
All public and hidden variables are fully accessible inside library.
All public variables from library are accessible to main.dart.
There is a problem. For some weird reason I can't use any directive with 'part of'. So I can't use this in the one.dart:
part of mylib;
import 'SomeClass.dart';
//somecode
So I either need to move class definition from SomeClass.dart to one.dart (and that will make code less readable and mixed up) or I need to move 'import' in the mylib.dart.
library mylib;
import 'SomeClass.dart';
part ..
I don't like either of the options. In the second case I will need to parse all modules then and move import/exports. Which will definitely break something.
It may sound weird but the project will build from various modules automatically. And one/ is one of them.
This app design is bad, I know. But either I need to find a better way or just make all variables public and don't bother.
Default to defining one type per file, not using part, and importing only the files you need. This covers the majority of use cases.
Now, let's say you have two types that are commonly used together - for example, a Thing and a ThingException that gets thrown when Thing does bad things. Importing both of these files everywhere is tedious, so you have three options with their own tradeoffs:
Declare both types in the same file.
Declare each type in its own file, and have the 'primary' file export the other. So, thing.dart exports thing_exception.dart. Importing thing.dart gives the importing file access to both.
Declare each type in its own file, and have the other file be a 'part of' the primary file. So, thing_exception.dart declares that it is 'part of' thing.dart. Importing thing.dart gives the importing file access to both files.
For this simple type and its exception, your best bet is to use option 1. When the amount of code grows or the two types diverge in visibility, this option becomes less attractive. This puts options 2 and 3 are on the table.
When you have separate files, option 2 is often a better approach than options 3 because you maintain some flexibility - you could only import thing_exception.dart and not thing.dart. If you use option 3, you can't do this - you either import all of the parts or none of them. This is the error you are seeing when trying to do a part and import in the same file.
Option 3 becomes valuable when you the code is in the two files is highly dependent on one another and they need the ability to access private members of each other. This is less common.
When you have a bunch of files like this together, it becomes a 'library' in the more traditional sense. You declare a main library file (your my lib.dart file) that exports files:
export 'public.dart';
export 'other_public.dart';
The bin script imports the library as a whole, but it can't see anything that isn't explicitly exported from my_lib.dart.
import 'package:mylib/mylib.dart';
Here's an example of a smallish package that uses all three of these options together for a good reference.
I think you will have better luck using import, and export with show. (Use of part of is now discouraged.)
Answers to this question may help you: When to use part/part of versus import/export in Dart?
Also the Creating library packages documentation: https://www.dartlang.org/guides/libraries/create-library-packages
I am trying to follow the steps to change the Gridworld appearance according to this. I've already imported source code for my gridworld jar file; ie. I can go and look at Bug.class or Gridpanel.class if I wanted to. However, I can't edit these files to produce the results that that pdf suggests. How do I do this? Did I import the source code incorrectly?
I don't think you can edit an external resource like gridworld.jar. You are going to need to create 4 new packages:
actor
grid
gui
world
Then copy the class files from gridworld.jar packages into your corresponding ones. Now you can edit the files. Make sure you include any miscellaneous files that might also be in the gridworld.jar packages, their important.
With your own packages you no longer need the gridworld.jar external resource, and there is a difference in your import statements. Instead of
import gridworld.actor.Actor;
Do this:
import actor.Actor;
Note: You will need to change all of the import statements in the new package classes to reference the other new packages. I believe that there were also some errors, not project breaking, but I just added suppressors.