In the ember-cli documentation it describes bridging the addon within your host application by overriding the app/component/[addon-name.js] yourself. However, the documentation doesn't explicitly state how to do this.
With trial and error I've noticed that by creating a component file in your [host app]/app/component/[name of addon.js] and simply copy/paste the addon code into there provides a venue to customize the addon. However, this is a terrible approach, I would imagine that I could simply override the functions in question...and in some cases call this.super().functionName in order to keep the over-rides simple and trim.
However, I can't get this to work. Any ideas?
Extensibility is why addons have both the addon/ and app/ trees. In the app tree for a component, the component should just be an import and export, for example:
import XSelect from 'emberx-select/components/x-select';
export default XSelect;
Source: https://github.com/thefrontside/emberx-select/blob/master/app/components/x-select.js
In this kind of case you want to create the component in [host app]/app/component/[name-of-addons-component.js] then in that component do:
import XSelect from 'emberx-select/components/x-select';
export default XSelect.extend({
//any overrides
});
Related
When using autoimport feature of nuxt3:
is there any impact (types, performance, bundle-size, tree-shaking, etc..) of using the # alias to import something rather than no import at all?
Or its only purpose is to make imports explicit and maybe help to fix some IDE/linter/ts issues?
Example:
// plugins/vuetify.ts
import { createVuetify, VuetifyOptions } from "vuetify";
import { defineNuxtPlugin, NuxtApp, Plugin } from "#app"; // this line should be optional
export const VuetifyPlugin: Plugin = defineNuxtPlugin((nuxtApp: NuxtApp) => {
const vuetify = createVuetify();
nuxtApp.vueApp.use(vuetify);
});
export default VuetifyPlugin;
I wasn't aware of the # import, do you have a reference for that specifc one?
As you kinda guessed it, there are no direct benefits of making the imports yourself. In the same way that Nuxt does the job for you regarding ref, computed, watch etc, it will try to import most of the other common stuff.
The compiler will scan your file, see what you are using in your template + script part and make the import himself on runtime. It may not guess fully dynamic imports (usually for components based on a dynamic variable for example).
Still, it should work in the exact same way performance-wise.
For the types I know that there could be some limitations (not a full coverage), but since I don't use TS, I'm not well aware of all the details.
Regarding IDEs/code editors, most of the time they will work fine but some of them may require a bit of configuration to work perfectly (since it's implicit, you still need to tell your editor what is happening), otherwise some Linters may complain a bit.
Nuxt's auto import feature is probably based on something really similar (if not identical) to this: https://github.com/antfu/unplugin-auto-import
Hence, you can see in details how this one works to get more explanation.
Well, I've read
https://medium.com/bootstart/you-should-be-using-folder-components-b30b7d165c39
article where author describes index.js as a cure and there is also comment in that article in which another person tells that it is redundant to make index.js in every component.
But! There are many repositories over github such
https://github.com/discountry/react/tree/master/src/components
https://github.com/geist-org/react/tree/master/components
https://github.com/reactjs/reactjs.org/tree/master/src/components
where they use index.js in every single component.
So, do we have to use them? Is it really necessary?
...it is redundant to make index.js in every component
Creating index.js helps in importing that component in different components/containers directly using:
import LayoutHeader from '../LayoutHeader';
instead of (without index.js):
import LayoutHeader from '../LayoutHeader/LayoutHeader';
Creating index.js in / for a single import element for an entire component feels redundant, but can be helpful when you want to have multiple elements in a single component (Not a very modular approach). Then you can use a single index file to export all the elements of the component.
Both practices are valid, and usually depends on programmer.
I am working to give my Angular 1.5 apps an upgrade with ES6 classes and I've been following Todd Motto's styleguide pretty closely so far. I have been naming component files like so:
|-components/featurename
|---featurename.index.js
|---featurename.component.js
|---featurename.controller.js
|---featurename.service.js
|---featurename.style.css
I have been naming classes like so:
const SomeComponent = {};
export default SomeComponent;
And then importing with the same name:
import SomeComponent from './featurename.component';
I'm wondering if dropping the featurename from all of this is going to cause problems with testing and debugging. It would certainly make creating feature boiler plates easier without a generator. I am proposing something like this:
|-components/featurename
|---index.js
|---component.js
etc..
const Component = {};
export default Component;
import Component from './component';
I believe you are free to orginize the sources in your project in a way you like to see them. The "featurename" prefix is useful for file-searching. I think this is the main point here. Let's imagine, we have 10 features, it means that we have 10 index.js files. Searching for "index" as a filename + "js" as an extension would give us 10+ results... in that case will have to search for feature specific folder. It may depends on the environment you are using for the development, there may be such a setup where it's not an issue.
I want to create an application wide variable accessible between various angular2 components and imported modules.
I have looked at dependency injection in my app.module and thought maybe I could set a class with a property in that. However, with the new angular-RC5 release, this looks like an overcomplication for what I want to do.
Alternatively, I thought of using a #Inputs and #Outputs to cascade the data and subscribe to changes, however, that doesn't seem to be possible between modules.
I would be really grateful for a suggestion of the easiest way of doing this.
In terms of my particular application, I have a navbar component which I want to show on all routes except one. So I have that on my app.component template, with an *NgIf condition, which I then wanted to be able to change from various child components to display the navbar, without having to embed the navbar component in all of my child modules and components (which gets tricky with components being shared between modules. Some of my routes are imported in a module.
You can create a shared service.
something like that :
import { Injectable } from '#angular/core';
#Injectable()
export class GenericService {
data:any = {};
}
and then add it to your app.module.
after that you can inject it to your component and add datas on it who will be accessible from all your components.
This is usually done using a shared service.
For details see
https://angular.io/docs/ts/latest/cookbook/component-communication.html
https://angular.io/docs/ts/latest/cookbook/rc4-to-rc5.html
https://angular.io/docs/ts/latest/guide/ngmodule.html#!#q-why-it-is-bad
About a year ago I have used Meteor, and now I want to use it again, but many things have changed.
When I follow the Blaze tutorial on Meteor.com, they add imports on top of their files:
import { Meteor } from 'meteor/meteor';
import { Template } from 'meteor/templating';
import { ReactiveDict } from 'meteor/reactive-dict';
I got the app working. But when I comment the imports out, the app keeps working like it should work. Why are these imports needed?
I am still using the regular Javascript, not ES6.
Thanks!
The import statement is used to import functions, objects or primitives that have been exported from an external module, another script, etc.
The name parameter is the name of the object that will receive the exported members. The member parameters specify individual members, while the name parameter imports all of them. name may also be a function if the module exports a single default parameter rather than a series of members. Below are examples to clarify the syntax.
Import an entire module's contents. This inserts myModule into the current scope, containing all the exported bindings from "my-module.js".
For more detail about the different ways we can use import along with their usage, please check this.
They still use the old globals for backwards compatibility. However it is recommended to use the imports so if in some future release they remove the globals your code will still work. You can read more in the appropriate section of the guide.
Ok you know import is to import an exported object from another file already.
The point that you may have missed is that MDG heard the need to stop loading everything by default, or at least to provide a mean to control what is loaded in memory and what is not.
Look for the /imports special directory.
Files in that folder are no longer loaded automatically, but only through import statement.
As for the tutorial, I guess they did not explained this functionality, and because it imports only standard functionalities which are still loaded eagerly for backward compatibility, it does not change anything removing those statements.