5
votes

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:

  1. All public and hidden variables are fully accessible inside library.
  2. 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.

2

2 Answers

12
votes

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:

  1. Declare both types in the same file.
  2. 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.
  3. 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.

1
votes

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