Another approach to look on this problem (very hard) about dep-configured-imports HOT 3 CLOSED

I too dislike the implementation. So I asked myself, how would I want to use this.

Essentially, I would like to create a package that contained library that when imported, would do the right thing depending on my environment.

So, how about this.

main.dart

import library.dart;

 // F3 Open Declaration => "interface.dart"
 // F? Open Implementations  => "server.dart" | "browser.dart"
var foo = new Foo();

library.dart

import basic.dart;

interface class Foo {
  Foo();
}

basic.s.dart

env server;

import "dart:io";
import "interface.dart";

implementation class Foo {
  File _file;
  Foo() {
    file = new File();
  }
}

basic.w.dart

env web;

import "dart:html";
import "interface.dart";

implementation class Foo {
  Element _element;
  Foo() {
    _element = new DivElement();
  }
}

The expected behavior would be, I'm in a browser, I will use the library portion that states it is for the web. We could even use the part functionality.

But this should hide the complexity from the user of the library, since s/he shouldn't need to deal with it at all. Remember, we want to keep Dart the clean language it is, not add verbosity that is implied.

from dep-configured-imports.

I think an interface library can be supported via a pattern like:

library foo;

import (conditionally src/server.dart or src/browser.dart which both contain a FooImpl);

class Foo {
  const Foo() = FooImpl;
}

from dep-configured-imports.

This approach assumes a fixed number of environments, and doesn't expand to user defined configurations.
It also requires loading a library to check whether it matches the current environment, which isn't desirable.

from dep-configured-imports.