I have a class named _AppColors. it contains all colors used in the application. I want to force developers to read colors from Theme that's why I made this class private. now I want to access this class from two files. but it can be only part of one file. how can I handle this?
app_colors.dart:
part of 'color_extention.dart';
class _AppColors {
...
app_theme.dart
import 'package:flutter/material.dart';
part 'app_colors.dart';
extension MultiThemeColorExtension on ThemeData {
...
color_extention.dart
import 'package:flutter/material.dart';
part 'app_colors.dart';
const TextTheme _textThemeLight = TextTheme(
...
but I have to add part of 'color_extention.dart'; in app_colors.dart which I can't. any solution?
Private symbols are private to the library. Normally a Dart library is a single .dart file, but part is used to specify that a library comprise multiple .dart files (and conversely, part of is used to specify that a .dart file is part of the specified library).
It doesn't make sense for a Dart file to be part of multiple libraries. If you want to share a private class with multiple .dart files, your typical options are:
Make all of those .dart files part of the same library.
Make your class public instead but discourage using them. Packages typically do this by placing internal implementation files in lib/src/ and exporting only the symbols intended for public consumption.
Related
If not - are there are any plans to make it so?
I know that dart itself has different backends that might have different implementation. I was curious if users can do the same, e.g. have a function that delegates to one #patch for js runtime and to another #patch in case of dart vm.
If you're creating a package, you can export different implementations for different platforms, see here: https://dart.dev/guides/libraries/create-library-packages#conditionally-importing-and-exporting-library-files
The way to make platform specific code (or rather platform library specific code) is to use conditional imports.
The syntax is:
import "helper_default.dart"
if (dart.library.js) "helper_js.dart"
if (dart.library.io) "helper_io.dart";
This import statement will import one of three libraries. If the dart:js library is available on the platform you are compiling for, you will import helper_js.dart. If not, and dart:io is available, then you will import helper_io.dart. If that's also not there, you will import helper_default.dart.
The trick is then to have the same library API implemented in all three libraries, but based only on the available platform library.
The helper_js.dart library can implement something using dart:js and helper_io.dart can import dart:io. The default library will likely not be able to do anything useful, so it might just throw an UnsupportedError if you try to use it.
The code in the importing library must be valid for all three imports, which is why they must have "the same" API. That might include declaring a class, but you'd usually define the interface of that class in a non-platform dependent library that the three implementations can share, to ensure that they actually have the same interface.
Example:
library mypkg.shared_types;
import "helper_default.dart"
if (dart.library.js) "helper_js.dart"
if (dart.library.io) "helper_io.dart"
as helper;
class SharedClass {
factory SharedClass(int something) = helper.SharedClassImpl;
int get value;
}
and
library mypkg.helper_io;
import "dart:io";
import "shared_types.dart";
class SharedClassImpl implements SharedClass {
int _id;
SharedClassImpl(this._id);
int get value { // Something depending on dart:io.
var bytes = File("pathToSomething-$id").readAsBytesSync();
return bytes[0];
}
}
I am making a flutter application and I created a file/class for each custom widget I am using. Then, I imported all of these files into the main screen but I don't like how it looks. Especially because if I want to add another widget or delete the one I would need to fiddle with the imports.
Is there something like C# namespaces where I can just make one import for all files in folder/namespace?
I already tried using library/part with success but then in https://www.dartlang.org/guides/libraries/create-library-packages says that I should avoid using part/part of. So, are we expected to import each and every file?
Instead of having:
import 'package:custom_widgets/custom_multiplechoice.dart';
import 'package:custom_widgets/custom_singlechoice.dart';
import 'package:custom_widgets/custom_time.dart';
import 'package:custom_widgets/custom_yesnochoice.dart';
import 'package:custom_widgets/custom_date.dart';
I would like to have:
import 'package:custom_widgets';
Yes there is, you can use export to achieve what you want.
You can place all your widgets in a folder, for example libs/src/ and then create file custom_widgets.dart in libs/ and use export like this inside custom_widgets.dart:
export 'src/custom_multiplechoice.dart';
export 'src/custom_singlechoice.dart';
export 'src/custom_time.dart';
export 'src/custom_widgets/src/custom_yesnochoice.dart';
export 'src/custom_date.dart';
Once you import custom_widgets.dart, all those widgets will be available to you.
Check this out, its all explained here: Dart: Organizing a library package
Update:
In Dart there are no namespaces like in most other languages.
Dart uses libraries for encapsulation, data hiding.
Only way to import a class into your code is to use import in the beginning of your file, which should also be a library.
I have an issue with this too. Imagine a situation where you want to import library dynamically. Let's say you would like to implement MVC pattern in your application, if you are doing this on the server, you would have a Router class that would analyze URL and decide what Controller class to instantiate and what Method from that Controller to invoke. Now every URL would trigger different Controller, and you don't know it in advance, its up to your Router to detect a Class to instantiate. What you need to do in this situation is import every Controller that could get instantiated at the beginning of your file. And I have issues with that. What if your application gets big and you have to import lets say 20 Controller classes, just so Router / Dispatcher can invoke one of them, and in reality you will invoke only one Controller, as there is only Controller per URL.
Don't have issues with manual loading of Libraries, if they are going to be used, but for situation like described above, Dart fails as there is no "auto loading" of classes like in for example PHP, where you can use auto loaders that use namespaces to find out about location of your class and instantiate a class in the middle of the code dynamically.
There is this extension for VSCode which can help to create this.
Dart Barrel File Generator
There are two ways to import packages in Dart programming language, I need to know what is the difference between them both, please?
Also when to use the first way and when to use the second way?
First way:
import 'dart:io';
Second way
import 'dart:io' as io;
as io specifies a prefix.
Without you can use members dart:io exports like
var f = File();
with prefix it would be
var f = io.File();
This is useful to disambiguate imports if names collide with declarations in your current library or another imported library.
Packages like path assume that they are imported with a prefix, because it exports many top-level functions with common names that without a prefix would clutter the scope.
I have a rather large Dart application that uses part and part of so that I don't have to use relative imports. However, the application may have something like this at the entry point file:
part 'file1.dart';
part 'file2.dart';
part 'file3.dart';
part 'some_sub_dir/file1.dart';
part 'some_sub_dir/file2.dart';
part 'some_sub_dir/file3.dart';
part 'some_sub_dir/file4.dart';
part 'some_sub_dir/file5.dart';
part 'some_sub_dir/file6.dart';
...
As far as I know, my IDE (WebStorm) doesn't automatically add a part statement when I create a new class. Is there any way I can avoid having to use so many parts? If not, can the process of adding new parts each time be automated?
I understand your problem as I can and I'll try to answer from my experience in Dart.
As I got it you are trying to keep all (or a lot) project files as parts of one library. It's wrong conception. In Dart library is not big thing. Here is few advices how to organize your files.
Don't try to keep a lot of files as parts of one library. Rather keep each file as separated library.
You can keep few classes in one file. But be sure classes works together for one idea.
You can split one library in few part files only if it has a lot of classes or one class is too big. But be sure all this files should be together in one library.
If you don't know how to combine classes in libraries keep each class in separated library. After days you will get understanding which classes plays together.
If one class from one library has usages in not only library but in other libraries - make it separated library.
Place parts in same folder with main library file.
If library has parts put all library files into separated folder.
Use relative links to parts.
Always use absolute links to other libraries. It will help you to make refactoring in future.
For example, this is a project like TODO list application. So, we have view class:
// This is a view html component class. //
library todolist.list_viewer;
import 'package:todolist/task.dart'; // model class
class ListViewer extends HtmlElement {
// it showes list of tasks
}
class TodoRenderer extends HtmlElement {
// this is a renderer for one todo item
}
And this is a model class:
// This is a todo model task //
library todolist.task;
class TodoProvider {
List<TodoItem> todos;
String addItem(TodoItem new Todo) {
//...
}
}
class TodoItem {
String Author;
DateTime date;
}
It looks simple now, divided into separated libraries. But if we want to add RecId class to keep todo database id it becomes too complex. We should split it in two libraries: todo_provider and todo_model and put RecId class into last one. Now it's good again.
If we wanna add one more model: a User, so each todo item may have executor or author. We can't just put it todo_model. Now we should to combine TodoItem and User classes into model library. So we just rename todo_model class to model and add User class into it.
Or instead last action we can make user_model library to keep User class. And as User model has recId property too we should extract RecId class into separated library.
It's all depends on how our classes big and complex.
I understand that:
part/part of is used to break a library into several parts (scripts). You have visibility to public and private members.
import is to "call/use" another library from your library. You have only visibility to public members of the imported library.
WebStorm can't infer you want a script to be part of your library.
I have the following import statements in a class
import 'package:dart_web_toolkit/ui.dart';
import '../../util/flex_table_builder.dart' as ftBldr;
import '../factors_list_view.dart';
class MediatingFactorsView extends Composite
{
//...
}
However, the last import statment is flagged with a warning:
The different imported libraries 'flex_table_builder.dart' and 'factors_list_view.dart' should not have the same name
The names are quite different and I see this being repeated throughout my code after I updated to the latest Dart Editor. Is this a bug?
Make sure that you are assigning library names to each file. The first line of the file should be:
library foo;
You should use different names for each library that you use. The library name is specified by the library directive, but anonymous libraries are treated as having the same name, which is where the warning comes from.
It is a warning in the Dart specification to import two libraries with the same name.
You can read more about how to use libraries here in the language tour.
You could follow the Package layout conventions.
For the error :
The different imported libraries onset_view.dart and duration_view.dart should not have the same name
you should define distinct library names in each imported dart file.
One additionnal note, you should use import 'package:epimss/shared.dart'; instead of import 'packages/epimss/shared.dart'; and import 'site_view.dart'; instead of import './site_view.dart';
The warnings correctly indicate there is a problem.
The correct solution depends on if the Dart files are conceptually separate from each other or are related.
Different libraries
If they are conceptually separate, then they should be defined as belong to different libraries with different library names.
The import command is used to reference a compilation unit from a different library, not a compilation unit that belongs to the same library. It expects every library to have a unique library name.
If a Dart file is treated as a library (i.e. is the subject of an import statement) and is not explicitly named then its implicit name is the empty string. In this case, both files are treated as libraries, and it is complaining about there being two libraries with the same name (of an empty string).
For this to work as separate libraries, given them different names:
Top file:
import 'foo.dart';
import 'bar.dart';
foo.dart:
library foo;
bar.dart:
library bar;
Part of the same library
But if they related they should not be referenced as libraries. That is, do not use the import command. Use the part command, which treats the Dart file as compilation unit that belongs to the same library.
Top file:
library baz;
part 'foo.dart';
part 'bar.dart';
foo.dart:
part of baz;
bar.dart:
part of baz;
Only the top library file can contain the part statements. You do not need (and cannot have) part statements inside the other files, even if they reference definitions from each other. If there are multiple files, just list them all in the top library file (in any order).
Although the implicit name for a library is the empty string, there is no way to use that when there are multiple parts involved: so even if these files are never going to be imported as a library, you will still need to explicitly assign it a library name.
Always remember: import and part statements are very different from the #include macro in the C preprocessor.