Ion-icon produce ion-null-icon- (Resolved)

Hi,

Thanks a lot for this useful framework, but at the moment, I’m getting a strange error. I think I found the problem but need help to resolve this.

Using a SharedModule, I have Angular components imported from a web project. In a component, I have:

<ion-icon name="icon-{{name}}"></ion-icon>

But this shows nothing because it generate:

<ion-icon role="img" class="icon icon-ios ion-null-icon-mind" aria-label="null icon-mind" ng-reflect-name="icon-mind"></ion-icon>

As you can see, I have a ‘null’. I think that the problem is the component isn’t aware about the ionic part and doesn’t find the device. Replaces manually null by md or ios displays correctly the icon.

In the SharedModule, I’ve imported like this:

@NgModule({
    imports: [
        // import all modules to share
        CommonModule,
        IonicModule.forRoot(EventCardComponent)
    ],
declarations: [
        // Declare all shared components/pipes/directives
        ...
        EventCardComponent,
        ...
    ],
    exports: [
        // export all shared modules/components/pipes/directives
        ...
        EventCardComponent,
        ...
    ]

EventCardComponent contains the previous code.
So, how can I do to finally have the prefix device? :slight_smile:
Thanks in advance

Found by accident the solution for those who are interested.

My sharedModule, containing all the components for a page, where outside Ionic. It means that it can use some functionalities of Ionic but not all the context. Putting all the components and services in the same folder of the page module and import/declare them as usual helps the app to find the context (and so, no null anywhere)

Hi @Armadof, would you mind sharing the actual code/structure/technique you did for this to work? I’m also experiencing the same thing, after I use this module in my app the icons were gone, https://github.com/mumairofficial/text-avatar.

Thanks in advance.

@Armadof, nevermind my question, I was able to fix the issue already.

What happened in my case was that I have a sharedModule for the TextAvatarDirective.

import { NgModule } from '@angular/core';
import { IonicModule } from 'ionic-angular';
import { TextAvatarDirective } from '../../directives/text-avatar/text-avatar';

@NgModule({
    declarations: [
        TextAvatarDirective
    ],
    // imports: [
    //     IonicModule.forRoot(TextAvatarDirective)
    // ],
    exports: [
        TextAvatarDirective
    ]
})
export class TextAvatarModule { }

And I just commented the part where I included it in the imports and it worked properly.

Thanks.

But isn’t using a single components.module.ts for all your components the recommended way of doing things?

I believe there something that we are missing to get it to work with the original approach.

I suppose that depends on who’s doing the recommending. I personally dislike that structure for two reasons: it contradicts Angular’s recommended arrangement of module-per-feature, and it exacerbates the code duplication problem inherent in the current state of webpack lazy loading.

In any event, I believe the answer to your questions is that you need to import IonicModule in any component modules that incorporate Ionic components. Not with the forRoot(), but simply importing IonicModule.

Thanks! That got it to work.

As for the structure, I thought the approach was intended to make it simpler to import components into pages/modules and that tree shaking would take care of dropping unused code anyways? Or am I missing something?

It’s considerably more complicated than that. The TL;DR version is that you get duplicates of all component code per lazily-loaded page. For the longer version with all the gory details, this thread is probably the single most comprehensive resource, but if you search for “lazy load duplication user:rapropos” (for example), you will probably pick up some of the earlier investigation and discussion.

That explains a lot. Thanks for the information.

So, is there any upside of having a single module for all the components?
Maybe if the app doesn’t use lazy loading or will it make no difference?

Again, you have to factor in that I’m one of the most opinionated posters here, and frequently said opinions are not very popular or commonly-held, so please solicit and consider other points of view.

That being said, I see zero value in the notion of having a single module for all components. As I probably said in that other thread, I consider it the worst of both worlds: failure to use modules to organize code logically and making current technical limitations worse.

If you have an app with lots of completely independent parts, you might benefit from lazy loading. If you are reusing your components in many pages, you may find (as I did) that it makes things actually worse. Until the duplication problem is solved, I would recommend for typical apps that they pretend the whole lazy loading business does not exist, and just declare everything in a single app module.