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?
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.
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.
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.
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.