I'm new to express and often see the code like this:
app.once('mount',function onmount(parent){
parent._router.stack.pop();
});
Not sure what is _router and why they pop it? Any reasons behind it?
The mount event occurs when a sub-app is registered with a parent app. The parent argument is the parent app object.
parent._router is the router associated with that parent app object.
parent._router.stack is the array of routes registered with that route.
parent._router.stack.pop() is removing the last registered route from that router.
There isn't enough context here for us to know why that last route is being removed. It's possible they are trying to remove the 404 error route (just a guess).
FYI, this direct manipulation of private instance variables is not documented behavior.
Related
Let's suppose I have a component called FirstPage, which is my default route, now FirstPage triggers an asynchronous call, with the help of an action of the vuex store, to be made each minute to a backend Api (it's triggered when the component is loaded as a route), now let's say I go to an about route that goes to an About component, is FirstPage still making the calls?
Edit:
I'm not developing an app with that yet, so I can't provide examples.
It's on my interest to know the behavior in these cases of the router, because whenever I change the route I would want to stop making the constant calls (as they won't be necessary).
The reason is that Depending on this I'd have to switch tooling for a project I have in mind.
In general, a component's instance will be destroyed when you navigate away from it. However, there are two exceptions to this ..
When you use routes with params. From the Vue Router docs
One thing to note when using routes with params is that when the user navigates from /user/foo to /user/bar, the same component instance will be reused. Since both routes render the same component, this is more efficient than destroying the old instance and then creating a new one. However, this also means that the lifecycle hooks of the component will not be called.
When you wrap your router-view component within a keep-alive element. Since the <router-view> is essentially a dynamic component.
Generally Vue does a very good job of housekeeping and cleaning up after a component's instance when it gets destroyed. But sometimes you'll have to do some manual cleanup, especially if you use some kind of external library. This is usually handled in the beforeDestroy hook of an instance's lifecycle.
In normal conditions, any logic/scripts/etc done at creation inside said component will be "purged" on the on destroy/close hooks (not only pertinent to vue but seen in lots of other tools), if there is a need to persist something then it should be in a higher scope (or other solution)
Any script written for the respective component only runs if the component is rendered in page. Once you go to about component replacing the previous component then previous script wont run.
you can make a parent component with a router-view and load in your page you always want to get loaded, so your FirstPage component, but this component should just have logic behind it, and no html because otherwise you will always see that rendered. Router-view the page you want to display the real html and stuff. I hope you get the idea, if not i could make an example for you. Goodluck.
If the destination is the same as the current route and only params are changing
going from one profile to another /users/1 -> /users/2.
How can I recognize this and update the component?
I'm not sure its the same for next.js but in due router even if the parameter changes the same component is reused. So you need to specifically watch the param changes.
From Vue router Documentation:
One thing to note when using routes with params is that when the user navigates from /user/foo to /user/bar, the same component instance will be reused. Since both routes render the same component, this is more efficient than destroying the old instance and then creating a new one. However, this also means that the lifecycle hooks of the component will not be called.
Take a look here: https://router.vuejs.org/en/essentials/dynamic-matching.html#reacting-to-params-changes
In Aurelia, the root view-model's (app.ts, containing router config) activate(params) method doesn't receive query string parameters.
For the address: http://localhost:5000/home?param=1, the Home view-model (home.ts) is able to read query string param via activate() method, but activate() params in App view-model (app.ts) are empty.
I have router configured to use pushstate, but the behavior is the same with disabled pushshate.
Is there a way how to read query string params inside app root view-model?
It's not going to get parameters passed to it b/c it isn't activated by the router. That being said, you can simply use VanillaJS to do this. There is a new API, that is polyfillable that you could use: https://davidwalsh.name/query-string-javascript
Remember, Aurelia is just JavaScript. This is something I say in every intro to Aurelia talk I give around the world, and it's important to take this to heart.
Can we have a state base routing in Aurelia JS like angular ui router
Currently I have routes like this
root/<userid>/<feature>.
Now I am just trying to implement the same in following way
root/<userid> and feature should be pass as a parameter.The problem is that
Once the component is loaded in memory it is not getting updated on params change.
TIA
You need to configure the lifecycle to be invoked any time the URL parameters change.
See "Reusing an Existing VM" at the link below.
http://aurelia.io/hub#/doc/article/aurelia/framework/latest/cheat-sheet/7
"Since the VM's navigation life-cycle is called only once you may have problems recognizing that the user switched the route from Product A to Product B (see below). To work around this issue implement the method determineActivationStrategy in your VM and return hints for the router about what you'd like to happen."
In your view model write the following method:
determineActivationStrategy {
return activationStrategy.invokeLifecycle;
}
I'm using Relay with React Native and have a problem during login & logout.
After login or logout, Relay keeps the store from the previous user. To solve this I use Relay.Renderer and Relay.Environment. As in, in each Renderer I put singleton object of Environment.
The problem is that I previously did a mutation on object of Relay.Store, as in
Relay.Store.commitUpdate(new CreateProfile(), callback).
Now it doesn't work. I guess this is because Relay.Store doesn't know anything about server endpoints. But Relay.Environment does.
And now I'm using something like this this.props.relay.commitUpdate(new CreateProfile(), callback). It works pretty well when the parent component is wrapped as Relay.Container, so it has relay object in props.
But what should I do in components which are not Relay.Containers and don't have Relay object in props?
Relay.Store is a globally accessible singleton instance of Relay.Environment and Relay.Store.commitUpdate() updates data in that global environment. But since you're using your own instance of Relay.Environment, to update it you need to use this.props.relay.commitUpdate(), as you noted. This updates the environment the container was rendered with.
If need to make mutations from child components of containers, that are not wrapped in a Relay.Container, there are two ways to do that. You could simply pass the relay prop to them, so in the render function of your container you would have:
<Child relay={this.props.relay} />
However, since those plain components are not in a Relay container, they don't currently need to know anything about Relay. If you want to keep them that way, you could write the method that does the update in your container component like this:
onCreateProfile = () => {
this.props.relay.commitUpdate(new CreateProfile());
};
and only pass a callback to your child component in render:
<Child onCreateProfile={this.onCreateProfile} />
If you need to make a mutation from a component that does not have a Relay.Container above it in the component hierarchy at all, you could create the Relay.Environment in a shared root component higher up and pass it down using props (or pass a callback using the strategy shown above).