Ok thanks. I think I’ll need to schedule this for sometime next week. It sounds like a project. But I’ll post here if I discover anything interesting.
Please don’t pollute this thread.
This seems relevant to what you are asking for: https://angular.io/docs/ts/latest/guide/style-guide.html#!#04-10
Also curious on @rapropos thoughts on the matter.
This should work. If it’s not working, it is a bug. Something we should note is the decorators themselves need to be statically analyzable. The code within the decorated class can be as dynamic as it needs to be. We extract the decorator data statically at build time.
Thanks,
Dan
I think either one of these will be fine. We went with IonicPageModule
to match the decorator, but really it is just a thin wrapper around IonicModule
. I don’t think there would be any harm in using it within a component. A benefit would be that whatever class is passed to is automatically analyzed for entryComponents
so you can skip that field in the NgModule
. That is not a huge benefit though .
Thanks,
Dan
hi , I have followed the instructions on updating the project… but I am having a problem in sidemenu navigation… I have tabs and sidemenu together… navigating between the pages/components on Tabs works fine, but in sidemenu it doesn’t work properly , it displays the root page when I try navigating to different pages ( the page displays momentarily but then disappears displaying rootPage ) in the sidemenu… Any suggestions!! thanx
I’m sure it was a typo, but just FYI:
** Typo nazi mode off **
Congrats on the release
Seeing some breakage here with DeepLinkConfig where routes aren’t resolving properly in 3.0.0. Are there breaking changes here and / or migration guidance?
nav-controller-base.js:75 Failed to navigate: undefined
core.es5.js:1085 ERROR Error: Uncaught (in promise): invalid link: LicensingInfoPage
Here’s my code from 2.2 that works:
// Deep links
export const deepLinkConfig: DeepLinkConfig = {
links: [
{ component: CartPage, name: 'Cart', segment: 'cart' },
{ component: LicensingInfoPage, name: 'Licensing', segment: ':statename/:licensetypename/licensing-info' }
]
};
According to the google doc (i.e. the Update Guide in the OP) you now define all those settings in the respective page’s IonicPage
decorator.
Yes, I saw that as an “Optional Step”. I think it may need to be moved to “Required”.
Yeah routing in general has been reworked, so I’ll add a note about it.
Also adding to some question regarding structure and setup of an app.
We’ll be adding some more notes the google doc about how we suggest things should be done for most people.
My difficulties with <ion-nav>
and string class names as rootPage
in a backing controller seem to have been a side effect of app-scripts #848.
I’m a bit confused because the google doc now says this:
Module Structure
Components
One module that imports all component classes, no individual modules for each component
Yet every time I create a new IonicPage I get a build error if it doesn’t have it’s own module:
/wiki-search-2.ts has a @IonicPage
decorator, but it does not have a corresponding "NgModule" at
/Users/roblouie/projects/ionic-3-beta/src/app/second-page/wiki-search-2.module.ts
So…how do I make it so I don’t need individual modules for each component? That error comes from app-scripts, don’t see a new version listed in the docs or anything. Thoughts?
EDIT: Sorry, nevermind, my guess is the answer is going to be that in Ionic land component != page.
Not sure if your edit clarifies this, but ATM I am only decorating pages with @IonicPage
. Components I am rolling my own modules for, and the strategy outlined in post 38 seems to be working. A further note: once ngc gets involved, those component modules need to be more aggressive about importing stuff like CommonModule
and IonicModule
. I had a few that worked in dev mode, but threw a slew of template parse errors under --aot
.
Hey,
Thx for Ionic 3! Upgrade (without the optional part) took me at most 10 min, everything’s working fine, great retro-compatibility job!
I’ve got following questions regarding the optional part:
-
Should the decorator @IonicPage() also be added to every modal? The doc says “For each “Page” in your application…”, not sure if I should count Modals as Pages… [UPDATE] Most probably yes, according conference app
-
@mhartington about your recommended options, if I declare a sub-component in component module, does this sub-component gonna be reloaded on each component access? or should I declare it in a main module?
Like
Component-A
comp-a.ts
comp-a.module.ts
declarations: [sub-component-1]
Component-B
comp-b.ts
comp-b.module.ts
declarations: [sub-component-1]
Accessing Component-A load sub-component-1, when I’ll access Component-B, does sub-component-1 gonna be loaded again if declared like this?
[UPDATE] About that, how to load and declare sub-/child-components correctly?
- Does preloadModules: true mandatory for lazy loading? Found it in the conference app but not in the migration documentation?
Conference-app:
imports: [
IonicModule.forRoot(ConferenceApp, {
preloadModules: true
})
]
-
The script (add-default-ngmodules.js) doesn’t generate any entryComponents for the pages-modules. In the conference app seems you added entryComponents for each pages-modules. What’s correct?
-
Is it correct that the referenced nightly documentation for deeplinker doesn’t exists anymore? (http://ionicframework.com/docs/v2/nightly/api/navigation/DeepLinker/ => 404)
I did update the doc a bit to explain things a bit clearer.
It really goes down to this.
- If you want a page to be lazy loaded, it needs an IonicPage decorator, and a ngModule that will load things.
For components/pipes we’ve settled on this setup, which we think will be the easiest out of the box
Components
One module that imports all component classes, no individual modules for each component
components/
- components.module.ts (ComponentsModule)
- imports and exports all components the user creates
-
component1/
- component1.ts
- component1.html
-
component2/
- component2.ts
- component2.html
Creating a page using generators automatically imports ComponentsModule
Pipes
One module that imports all pipe classes, no individual modules for each pipe
pipes/
- pipes.module.ts (PipesModule)
- imports and exports all pipes the user creates
- pipe1.ts
- pipe2.ts
Providers
No NgModule for providers, import each provider in main app NgModule
providers/
- provider1.ts
- provider2.ts
Now a lot of this work will be handled by the generators, so it will be automatic for the most part. If a dev wants more fine-tuned control, they still have the option to do that. But having things setup this way will provide the easiest path for most people.
thx for the answer!
-
in app.module, I should then import and export ComponentsModule and PipesModule too?
-
should ComponentsModule and PipesModule be imported in app.module as simple module or should they be imported to be unique like ComponentsModule.forRoot() etc.?
A bit off, but pipes.module and components.modules get added to the import
of each ngmodules that they’re used in.
@rapropos sorry, if it doesn’t bother you (too much), don’t you mind sharing your CustomPipeModule’s code?
I’ve to accept the fact that I’m freaking to dumb to achieve it or unsure about mine:
import {NgModule} from '@angular/core';
import {FormatCurrencyPipe} from './core/currency/format-curreny-pipe';
@NgModule({
declarations: [
FormatCurrencyPipe
]
})
export class PipesModule {
}
I’m trying to migrate form 2.3.0 to this new version but i have an huge problem with new router system.
In fatc when i try to launch my app (after update).
In fact my page is load and very quickly after I have this message:
Error: Uncaught (in promise): invalid link: myPageName
Some have a similare issue ?