2017-11-06 1 views
1

ionViewCanEnterが決定する前にページが読み込まれることに気付きました。ユーザーはページを閲覧することさえ許可されています。Ionics 3ガードの問題

このため、テンプレート内のすべてのコンポーネントが常に構築されます。

IMOでは、特にコンポーネントがコンストラクタでHTTPリクエストを使用してデータをロードする場合、これは実際には非効率になります。

私は何か間違っているのですか、より良いガードアプローチがありますか?

単純レプリカ

テストpage.html

<ion-content> 
    <test></test> 
</ion-content> 

テストpage.ts

... 
ionViewCanEnter() { 
    console.log('ionViewCanEnter?'); 
    return false; 
} 
... 

テストcomponent.ts

... 
constructor() { 
    console.log('TestComponent Constructed'); 
} 
... 

コンソール

TestComponent Constructed 
ionViewCanEnter? 
+0

'ionViewCanEnter'をどのように扱ったのか、' code'を表示できますか? – Sampath

+0

私はネイティブストレージからトークンを取得し、(同期)JWTヘルパー関数でそれを検証する約束を返します: –

+0

'code'を表示できますか? – Sampath

答えて

1

あなたはIonicPage/Componentのデザインに反している別の何かを期待しています。

ionViewCanEnter

ビューを入力する前に実行します。これは、あなたはそれがruns before the view can enterを言うことがわかります

を入力することができますあなたが ビュー、あらかじめアクセス許可を確認する必要がある認証されたビューで 「ガード」の一種として使用することができます。 ビューが作成される前にが作成されています。Pag​​eのviewが作成されている場合は、componentspageであり、これもconstructedであることを意味します。しかし、あなたはcomponentのデータ検索方法を変更することができます。つまり、ionViewCanEnter()のロジックに従ってEventを発行する必要があります。その後、subscribeからeventまでcomponentのデータを取得することができます。その後、コンポーネントのconstructorのデータ検索を削除できます。それ以降はすべてうまく働いていることを願っています。

+0

あなたが正しいと思われますが、あなたが私に尋ねた場合、このガードアプローチはパフォーマンスのリークを引き起こします:それはページ全体を構成し、あなたはここにいることさえ許可されていない! ' ionicチームが将来的にはより良い解決策を見つけたり、Angular自身のアプローチを何らかの形で可能にしてくれることを願っています。とにかく、イベント購読で良いアイデア。 –

+0

私はあなたにここで同意しない。あなたは 'false'ユースケースのみを考えています。それは、「あなたがここにいることさえ許可されていません!」と言っています。「真の」ユースケースはどうですか? 「true」の場合、ページ全体が作成されるまで待つべきだと思いますか?だから我々はいずれかの方法でパフォーマンスのリークが発生します。だから、「イオニック/アンギュラント」チームはそれを選択しなければなりません。彼らはここで 'false'ユースケースを選択しました。そして私はそれも必要であると思う。 'page'を構築することなく、' ionViewCanEnter'ライフサイクルフックについて考えることさえできないからです。 – Sampath