home.html
<ion-content>
<ion-list inset>
<ion-item>
<ion-label>Search</ion-label>
<ion-input [(ngModel)]="username" type="text"></ion-input>
</ion-item>
</ion-list >
<div padding>
<button ion-button block (click)="changePage()">Search</button>
</div>
</ion-content>
home.ts
changePage(username){
console.log(this.username);
this.nav.push(ListPagePage,(this.username));
list-page.ts
constructor(private navParams: NavParams, public homepage :HomePage, private http: Http,private nav: NavController) {
this.navParams = navParams;
console.log(this.navParams.get(this.username));
}
Change
this.nav.push(ListPagePage,(this.username));
to
this.nav.push(ListPagePage, {username: this.username} );
Then on list-page.ts make these changes:
constructor(public navParams: NavParams, public homepage :HomePage, public http: Http, public nav: NavController) {
console.log(navParams.get(‘username’));
}
Why are you advocating making all those members public? They aren’t likely to be referenced from a template.
If you use the ionic generate function, you will see they use public for their items in the constructor. I believe this the pattern what most ng2 folks follow. Since they really don’t matter at runtime (public v. private), it doesn’t matter in the end.
I think, if for no other reason, it matters from a self-documentation perspective. If I am not intending object properties to be accessed from outside the component class (“outside” including from its associated template), I mark them private and prefix their names with an underscore.
Then when I come back to this class later, and wish to change something, I know at a glance whether or not any consequences will be limited to this single file.