I'm making an app in Flutter. I'm wondering if importing the same thing across many files has a negative effect on performance. For example:
Files a.dart, b.dart, and c.dart use import 'package:firebase_core/firebase_core.dart';
Should I instead create a new file z.dart which uses this import and contains all the functions my program needs from this import? With this new file, I would have the others use functions from z.dart so the import only gets called once. Does this help or does it make a difference if they all import the same thing?
The answer is no.
Flutter only import file once, only when the file executed like this
new Home() <- all import inside home class will be executed once
Related
I have a set of Swift Packages that I'm writing (ex: CUIExpandableButton), that I'd like to roll up into another Swift Package called CrystalUI. The overall goal is to write a set of packages that get bundled into a single package. However, I want to make it so people can just have one import
import CrystalUI
instead of a series of import statements
import CrystalUI
import CUIExpandableButton
import PreviewKit
...
Is it possible to re-expose an existing library as part of the parent library?
Looks like #_exported Is what I was looking for. Found this article that explains it. It's an unsupported method but it's also used in Alamofire so I think it's safe.
I'd like to import Control.App into a module that refers to PrimIO.PrimIO via the unqualified name PrimIO in a lot of places. The problem, of course, is that Control.App also exports a definition named PrimIO. I would like to minimize the damage by importing either only App or everything but PrimIO from Control.App; i.e. what one would do with import Control.App (App) or import Control.App hiding (PrimIO) in Haskell.
What is the Idris2 way of doing this?
Based on #michaelmesser's comment, I was able to get this working with the following:
import Control.App
%hide Control.App.PrimIO
However, this doesn't give me a good way of explicitly referring to Control.App.PrimIO when I do need to refer to it.
Instead of writing :
import 'package:flutter_platform_widgets/flutter_platform_widgets.dart';
which exports a dozen of files, I would like to write :
import 'package:flutter_platform_widgets/flutter_platform_widgets.dart'
show
PlatformAlertDialog,
PlatformCircularProgressIndicator,
PlatformDialogAction,
PlatformText,
showPlatformDialog;
because I'm only using these components. However this is quite tidious (reminds me of Typescript's endless imports) and goes against Dart's principle of briefness.
Imports snippets in VSCode uses the first solution, but is there any notable difference, for example in terms of performance? Is there some kind of good practice? I cannot find anything in official guidelines.
There is no impact on performance. The reason of using show is to reduce chances of confusion when importing classes from different packages.
For instance: Let's say
abc.dart has 2 classes
class One {}
class Two {}
And xyz.dart also has 2 classes:
class One {}
class Three {}
And you are importing both package in your file
import 'abc.dart';
import 'xyz.dart';
Say, you only want to use class One from abc.dart, so when you use One it could be from abc.dart or xyz.dart. So to prevent One coming from xyz.dart you'd use:
import `xyz.dart` show Three // which means only `Three` class can be used in your current file from xyz.dart package
When you use the keyword show basically what you are saying that I only want to use this specific class from this package in your dart file, from the docs:
Importing only part of a library
If you want to use only part of a library, you can selectively import the library. For example:
// Import only foo.
import 'package:lib1/lib1.dart' show foo;
// Import all names EXCEPT foo.
import 'package:lib2/lib2.dart' hide foo;
Now if you try to use anything from this package other than foo you will get an error because you specified that you only want to use foo.
I'm about to try implementing some IoC/DI framework in our application (thinking of Inversify, if there are any other recommendations) but we still have the problem of having to include the files for their Types. How do we get around this? We're using the latest version of TypeScript (2.3 as of writing this).
We have a lot of imports for various types, for example:
// Components
import {GuideTime} from '../components/guide-time/guide-time.component';
import {GuideNetwork} from '../components/guide-network/guide-network.component';
import {GuideDetail} from '../components/guide-detail/guide-detail.component';
import {Player} from '../components/player/player.component';
// Services
import {Keys, KeyService} from '../core/services/key.service';
import {GuideService} from '../core/services/guide/guide.service';
import {afterCSSUpdate} from '../core/services/utility.service';
import {DataService} from '../core/services/data/data.service';
Or just to get the type of something:
import {ITitle} from '../../models/title.interface';
import {IGuide} from '../../models/guide.interface';
Is there a way to consolidate these (preferably automatically, or globally)? I realize I can probably make a mytypes.ts file somewhere and then just import and export all the types from our application so there's a single, central file to import, but that introduces other problems (and a lot of work).
Thanks!
To make all of these global you would need to import them all to a single interface, and then import that interface wherever you need access to every type. Something similar to
import * as mainInterface from 'MainInterface'
Additionally, you could try importing for side effects only (which would give you access to the types), although this is not recommended in practice.
From the documentation:
Though not recommended practice, some modules set up some global state that can be used by other modules. These modules may not have any exports, or the consumer is not interested in any of their exports. To import these modules, use: import "./my-module.js";
EDIT Additionally, similar to the above single interface solution, you can put each of the types into the same namespace. You can spread a namespace across multiple files using this approach, which means you can just wrap each type in a main namespace.
namespace MainNamespace {
export class GuideTime {
...
}
...
}
I'm writing a small simulation program in Scala. It is actor-based so I've created a file messages.scala that contains all of the messages that are valid in the system.
Outside of this, I have a management component, management.scala and a file that defines the nodes and links classes nodes.scala. Management and node files both import sim.messages._ and then management does import sim.nodes._ as it needs to be able to instantiate things from that file.
The problem comes with one message type Tick that is used by both management.scala and nodes.scala. Upon compiling the management component, I get:
error: reference to Tick is ambiguous;
it is imported twice in the same scope by
import sim.nodes._
and import sim.messages._
I tried removing the import of messages in the management component since they were apparently already imported in to this scope but then they couldn't find them anymore. Ideas?
Try
import sim.nodes._
import sim.nodes.{ Tick => NodesTick }
and/or
import sim.messages._
import sim.messages.{ Tick => MessagesTick }
Of course, you will have to rename the references to Tick with the right one.