I'm building up some Dart code that I would like to use in an app where it is essentially a library to the javascript. I'm wondering how I can specify which Dart files I'd like in the project to be part of the library. For example, theres Foo.dart and Bar.dart. How can I have the created product include both Foo.dart and Bar.dart in one file? I'm also concerned about tree shaking since none of the classes are instantiated in Dart.
There's also a Baz.dart, and I would like to have a different build for compiling Foo.dart and Baz.dart into a single file (though this is less important, as I can accomplish this would separate projects and some symlinking).
Thanks!
This use case (build a JavaScript library with Dart) isn't supported yet.
The reworked js-interop package is supposed to allow to do that but I don't know about it's current state.
Related
Effective dart says
"DON’T import libraries that are inside the src directory of another package."
reason being it breaks abstraction and could potentially break your app if the library was to change its underlying implementation.
They do not provide an alternative or a solution.
Im currently working on a dart package that my app depends on.
What would be the correct way to import the models or classes from it instead of importing it directly from package src folder?
As previously mentioned in the comments, you can define which classes you can expose from your package. You're correct that it's recommended to avoid exposing more API than intended - it's also mentioned in the docs. To do this, you can define the exposed classes:
export 'src/your_file.dart' show ExposedClass hide HiddenClass;
I do not completely understand the difference between part/part of and import/export when using libraries in Dart. For example:
one.dart:
library one;
part "two.dart";
Class One {
};
and
two.dart:
part of one;
import 'somefile.dart';
Class Two {
}
versus
library one;
import 'two.dart';
Class One {
}
and
library two;
import 'somefile.dart';
export 'somefile.dart';
Class Two {
}
Both scenarios seem to do the same thing. When is it advantageous to use part and part of rather than import? And are there scenarios where import will not work, but part and part of will?
update 2018/03
part and part of is used more and more for code generation scenarios recently (instead of deprecated transformers) and unlikely to go away anytime soon.
Packages like built_value, json_serializable, and many others depend on it.
Discouraged is only the patter where all files of a package are tied together to a single library by having one library file and all other files being part of that library.
original
In Dart, private members are accessible within the same library. With import you import a library and can access only its public members. With part/part of you can split one library into several files and private members are accessible for all code within these files.
see clarifications to below paragraph in above update
Using part / part of is discouraged and the Dart team is considering getting rid of it. I assume they will introduce something like "friend" (https://github.com/dart-lang/sdk/issues/22841), where two libraries can access each other's private members as an alternative before they discontinue part / part of (maybe in a future Dart version).
Let's suppose we have a Dart library called mylib, whose file is lib/mylib.dart.
library mylib;
// Definitions
That library can be included in the main.dart file as
import 'package:mypackage/mylib.dart';
When you create a new library and use other libraries you want to make available automatically when using your package, then you use export:
library mylib;
export 'otherlib.dart';
// Definitions
You can use the show keyword to import/export only some parts of a library (like a class or something).
You are using the part of directive wrong here. You can't use both library and part of, which is used to specify the contents that belong to a library. For example, you can split your library file in more than one file (the parts):
Suppose we have in the file mylib.dart:
library mylib;
part 'src/class1.part';
// More parts
And then we have in another file src/class1.part the part specified in mylib.dart
part of mylib;
class Class1 {
/* ... */
}
The Creating Library Packages article on the dartlang.org site recommends avoiding part / part of.
Note: You may have heard of the part directive, which allows you to
split a library into multiple Dart files. We recommend that you avoid
using part and create mini libraries instead.
The 'mini libraries' referred to are small library dart files in src which are imported into and exported from main libraries.
using part/part of makes many files be treated as if they were one file
import/export doesn't, so this may be useful when private fields need to be accessed from another files (classes created on other files)
I am curious to know if its possible to have Asynchronous module definition with Angular.dart (or dart in general), if yes, then please share a sample code for such a single page application.
AMD is made largely irrelevant by the fact that Dart comes with a complete module system that is built into the language. That is the purpose of the import statement. Dart files are dynamically loaded in Dartium. If you are using the darttojs transpiler, it will create a single large file. The solution to this is to use use the DeferredLibrary class which will cause darttojs to create separate javascript files for each annotated import
See Seth Ladd's blog post for more details.
I'm developing an iOS SDK that integrates other SDKs (Facebook SDK 3.5, for example).
To prevent collisions and allow my customers to import those SDKs as well, I want to rename all of the classes/enums in my code (for example, rename FBSession to RDFBSession, etc).
Is there an easy way to do this instead of going class-by-class and using Xcode's rename feature?
Apple provide a command-line tool called tops(1) that is designed for scripting large-scale code refactoring (renaming C functions, Objective-C methods, classes, and other tokens):
tops -verbose replace "FBSession" with "RDFBSession" Sources/*.[hm]
If you have a lot of replacements, you can put all of the replace... commands into a file that you pass with the -scriptfile option. The man page has more information on the more complex commands/options (and examples).
Xcode also offers textual Search and Replace. This will be faster than individual refactors, but it is ultimately less automated. You can make the step by step refactoring faster by first minimizing the project to the relevant dependencies/sources (if possible).
However, renaming the declarations in a library will not alter the symbol names of its associated binary. If it is distributed with a binary, then renaming will just result in linker errors or (in some cases) runtime errors.
The best idea if you need to use a 3rd party library which your clients might also use is to simply inform them they need to link the library with their app, then publish the version(s) the current release supports so they know they have some extra testing if they go too far ahead with some libraries.
I think that a better approach than simply renaming your classes would be to download Facebook's open source code, rename the classes there and compile a new static library with a set of renamed header files. Then you can be sure that no collisions occur and that you're using symbols that you named yourself.
I must warn you though - working like this may make updating the SDK a nightmare regardless of how you tackle this specific issue.
I am working in a very large iOS project and it has so many classes and resources that it takes very long time to index and compile them. As it still grows more and more, I need to do something about this because I am spending too much of my time waiting for the IDE to let me work.
My first idea was to pack all the images in a custom bundle so the IDE will see it as a single file and would be faster to index and copy it, but I have seen that a bundle is nothing more than a simple folder with an extension, so I guess that the performance would still be slow. Then I read that if I used "blue folders" instead of "yellow groups" for my images, Xcode would not index them. But this way is not easy right now, as I should replace my function that looks for images to look for them in that folder (absolute paths?)
So my last approach will be saving time in both compile time and indexing. I want to modularize my code in multiple libraries so it will not be necessary to compile it "ever" again and this way Xcode won't need to index the source files neither.
I have followed some tutorials and now I know how to create a static library and include the header files in another project. But my current problem is as follows.
My application has several "independent" modules, so I want to create a static library for each one (and maybe I'll generate an image bundle for each one too...). But all of those modules use a common core, which I'd like to maintain in a static library too. So, if I do it like this, I will have to include the main core library in every module library, and I'm afraid this will not be the most optimum way, as the binary code of the core will be there several times, right?
I guess the correct solution would be to generate a dynamic library for the core and static ones for the modules, but I can't find how to generate the dynamic one... Furthermore, I'm not sure this would be the solution.
So I ask you: what options do I have? Is compiling the core several times the best approach I have?
Thank you so much for your help!
Dynamic linking is not supported in IOS, so this isn't an option. While the static libraries are added to the other libraries, it isn't embedded inside the other static library, you can see this when you do a build, the other libraries should show as a separate libraries inside the project folder, hence each static library/project will only get included once in the app build.
In the end ... I am not sure this will save you a lot of time you are expecting if you are using static libraries in the same workspace. I use static libraries in some projects and if I do a Clean on the app, then a build, the static library will get re-built also.