My problem is that my route data is still there after refreshing the page, is there a way to remove it so that it doesn't exist after/before I refresh the page?
I have a stackblitz that mirrors my code: whenever I navigate from a specific route Customers to Contacts, it should scroll down the page.
It does this but when I refresh the page, it STILL scrolls down.
I only want the scroll behavior to happen if it navigates from Customers to Contacts, not any other route or refreshing the page. Unfortunately, stackblitz isn't able to show the problem I'm having since I guess refreshing on stackblitz isn't the same as refreshing the browser.
Stack: https://stackblitz.com/edit/angular-hipega-brjh36?file=src%2Fapp%2Fapp.component.ts,src%2Fapp%2Fapp.component.css,src%2Fapp%2Fapp-routing.module.ts,src%2Fapp%2Fcontact%2Fcontact.component.html,src%2Fapp%2Fcontact%2Fcontact.component.css,src%2Fapp%2Fcontact%2Fcontact.component.ts,src%2Fapp%2Fcontact%2Fcontact.module.ts,src%2Findex.html,src%2Fapp%2Fapp.module.ts,src%2Fapp%2Fcustomers%2Fcustomers.module.ts,src%2Fapp%2Fcustomers%2Fcustomers.component.ts,src%2Fapp%2Fgreeting%2Fgreeting.module.ts,src%2Fapp%2Fgreeting%2Fgreeting.component.ts,src%2Fapp%2Fapp.component.html
Not sure of your exact problem, but I imagine if you use the OnInit or OnDestroy lifecycle hooks, you will be able to solve your problem.
I would say use OnDestroy and then remove the parameters from the route before doing so using Router.
constructor(private readonly router: Router) {}
ngOnDestroy(){
// for demo purposes, you may need to find something more appropriate for your case
this.router.navigate(["/"])
}
https://angular.io/api/core/OnInit
https://angular.io/api/core/OnDestroy
Related
Is there any way to reload my Angular 11 app without window.location.reload() and ngOnInit()?
window.location.reload() makes Chrome reload the tab which is not my desired outcome. And ngOnInit() causes some wierd bugs in my app.
I would like to have something similar to window.location.reload() but that doesn't refresh the Chrome tab.
Any solutions to this?
Thanks in advance.
it looks like without any data you approach is wrong, you can use ngAfterViewInit or one of the life cycle hooks with element refresh. however if you are trying to refresh data on the screen you should look at service binding so that the data is "reactive".
you can use behavior subject or subject binding but it makes your data as a subscribed event so its updated without redrawing the viewport.
however without any type of code or anything this is only speculation.
I have a router with a lot of screens and nested navigators, and everything is working exactly how I want it to. I'm using redux for a lot of state throughout, but I'm not using redux for navigation state.
If something unexpected goes wrong, for example no network connection, an alert comes up. Once the alert is dismissed, there may be some missing information on the screen. I did the "pull down to refresh" thing using RefreshControl and StackActions.reset in a couple of the most common places with ScrollViews.
I suppose it's possible to write this refresh function for every single screen to re-fetch data on pull-down refresh, but it seems wrong, like I should be able to get the navigation state from anywhere and then use StackActions.reset to reset the navigation state to exactly where it was where the actions are navigations to everything in the stack using a generic refresh function. Having a bit of trouble deciphering the navigation state to be able to do this generically from anywhere though, has anyone else done something similar?
try
navigation.replace(routeName)
I'm working on a project using react with flux architecture.
I have several views and a store called ContextStore in which I save the current view in the state, so that when an action to change the view is triggered this store change his state and the Main view listen and change it.
But the problem is that always when I refresh the page with F5 it always goes to the initial Views.
What is more, if I press the back button the View has no change.
I think that my problem is because when I refresh the Main view loads again the initial state. How could I solve it?
Thanks!
You might want to look into using a router to manage your views. Here's the one I use: https://github.com/rackt/react-router. When you transition to different views (routes) it adds to the history stack so you can use the back button. However, I don't have the use case where you need to stay on the current view when you refresh, so you might need to use cookies or session storage in those instances in any case.
You are right, when hitting F5 you are completely reseting all javascript, ergo the store looses its state. You need to use some kind of storage for saving the state. Classical ways are cookies, or you could use IndexedDB which is included into HTML5
I am working on an ember.js (version 1.2) based mobile application and I am trying to find the most idiomatic way of implementing the global menu toggle/back button pattern that is common in many mobile apps. Specifically, its a button that sits on the left side of a fixed-top toolbar, which toggles a hidden drawer main menu when the user is at the app's home/index view, however upon moving into a sub route, the button displays a back arrow, and when clicked, it takes the user back to the previously viewed route (or back to the index route if there is no previous history states, i.e. if the user came into a sub route directly upon loading the app).
Fyi, currently I have my app structured with the fixed-top toolbar and menu toggle/back button in the root application template. Ideally this functionality would work no matter how a routes are being transitioned to, whether via transitionTo(), or {{#link-to}} helpers, ect.
So essentially I want to know if Ember internally maintains any sort of accessible history/log of what routes were transitioned to over the course of the app's lifetime, and also what would be the best way to conditionally change the action that the toggle/back button performs and its display (aka its icon) depending on the current route. And/or is there a way to listen to ember's route change events so I could implement that history myself if need be?
I hate to be the bearer of bad news, but I also hate to leave you hanging.
Ember doesn't keep track of the history, there isn't a general use case for it (especially since the browser keeps track of it for you).
Fortunately you can monitor route changes in the application controller, something like this should get you started (Note I didn't spend time working out an awesome solution that works perfectly, just showed you the basics you need for it, I'll let you figure out the workflow that works well for you)
http://emberjs.jsbin.com/IZAZemEP/1/edit
App.ApplicationController = Em.Controller.extend({
history: [],
hasHistory: function(){
return this.get('history.length')>1;
}.property('history.length'),
watchHistory: function(){
this.get('history').pushObject(this.get('currentPath'));
}.observes('currentPath'),
actions: {
goBack: function(){
// implement your own history popping that actually works ;)
if(this.get('hasHistory')){
this.get('history').popObject();
window.history.back();
this.get('history').popObject(); // get rid of route change here, don't need it
}
}
}
});
I've run into this on a few apps now, so I wonder if I'm doing something wrong with Backbone history. Here's the situation...
I have two pages, let's say:
index.html
app.html
The index page is just a normal, flat HTML page with a link to app.html. On the App page, Backbone.history.start() is called to fire up hash state management, which is used to toggle between two views on the App page, say:
app.html#search
app.html#results
So, navigating back and forth between the #search and #results pages works great. No problems there. The issue occurs when you try to use the back button to step all the way back to index.html. The path back to the index page involves a stop at app.html (no hash state), at which the Backbone router dutifully fills in missing hash state, putting you back at app.html#search. Again, clicking the back button will go to app.html, which fills in the missing hash state again... basically, you're now stuck in a loop and can't go back from the page. This same behavior occurs when using push state.
This seems like a potentially common problem with apps that automatically fire up their own routing system on top of a default page URL. Does anyone know of a good way to avoid this?
The problem is that app.html isn't doing anything on it's own; and so, may somehow break the app if navigated.
In this case, what you could do is instead of redirecting the root route to another, just use it as the default page:
routes: {
"": "search",
"results": "results"
}