-
-
Notifications
You must be signed in to change notification settings - Fork 404
Description
I've been trying out ember-template-imports in my app, really liking this new way of defining components so far. Thanks to everyone who made it happen.
One thing that's been bothering me slightly is the number of imports that some of my components need. I'm sure that better editor support will help, as will a possible future consolidation of core Ember imports, but I wish importing common things wasn't so scattered and verbose, eg:
import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';
import { service } from '@ember/service';
import { on } from '@ember/modifier';
import { array, hash, fn } from '@ember/helper';
export default class extends Component {
@tracked isVisible = false;
<template>
...
</template>
}I think there's an opportunity to simplify these imports.
In my own app, I've stared to re-export common built-ins:
<my-app>/index.js
export { default as Component } from '@glimmer/component';
export { tracked } from '@glimmer/tracking';
export { service } from '@ember/service';
export { on } from '@ember/modifier';
export { array, hash, fn } from '@ember/helper';Which makes importing much simpler:
<my-app>/components/modal.gjs
import { Component, on, or, tracked } from 'vidu-web';
export default class extends Component {
@tracked isVisible = false;
<template>
...
</template>
}Perhaps we should make a change in the framework to make importing common built-ins simpler? A few possibilities:
1. From @ember:
import { Component, on, or, tracked } from '@ember';2. From @ember/<edition>:
import { Component, on, or, tracked } from '@ember/polaris';3. From <my-app>: (we'd change the blueprints to do the re-export)
import { Component, on, or, tracked } from '<my-app>';