I have a navbar as a shared component that is used in the Perspective Page Configuration. The component is living in Perspective/Views/Components/Navigation/<Large/Small> and is used in the Perspective/Views/Components/Navigation/BreakpointHorizontalMenu.
Is there a way to get the url parameter in the deep nested view? I see that the page has the urlParams but those are query paramenters instead of url parameters.
I'm pretty sure you will have to pass them inward at every level that needs them.
Thanks for the prompt replay.
That is not my question, my question is how to get the value from the URL to begin with. After I have the value, yes, I need to pass the value inward throw all the nested views.
That's automatic in the page configuration--they are delivered to the matching view parameters of the main view.
Have you checked Ignition's documentation? Pages in Perspective | Ignition User Manual
Thanks for the replay,
Yeah... the use case shown in the User manual is in the wrong direction of my use case. The use case in the manual is to let ignition user a number set in a view property to then set the url parameter that is set in the route.
Using this use case, here is my use case. After that happened, that a view has a tankNumber that ignition intercepted to set the url parameter and rendered a totally new view, in this new view that just rendered, I need access to that URL parameter /tank/2. It was set by a different view (and I got that working), but this new and different view needs access to the URL param /tank/2. In my use case I don't need to set the url param, I want to use the url param in the view. it is the other way around. Hope that makes sense.
I would only use URL params at the top-level view, then pass it down through further embedded views via normal params and bindings.
The script that is opening the new view must set its parameters. That is an "inward" operation, just like embedding. 
By rendered, do you mean you are using the system.perspective.navigate function? If so you pass parameters via Dictionary[String, String] and voila, this new rendered view has the information you want it to have.
pturmel -- dillon.therrien
I have a web background and it is difficult for me to do what you are suggesting. What you are saying is... because the view that set the url parameter has the value to the nav bar that is in the embedded view, I'm not going to even wait for the next view to load, I'm going to assume that view is going to render/paint-the-html with all the data that it needs.
Seems like there is a lot of magic happening under the hood here but the life cycle of what is happening, and you are suggesting, is not normal. In a request/response, the response is the new page, and it should be totally decoupled from the previews view. I should not have to tell the view to pass down the id because I don't know if the page actually rendered at all.
It seems that this is an asynchronous operation ignition is doing and assuming that the response to the server from the previous call is going to be there regardless.
You'll be better off sending a few screenshots of what you're looking at and trying to do - sometimes its hard to explain but very simple to show.
Perspective is not a request/response application. It is a single page application built with React. If you navigate to pages, the view associated with that page will receive the URL parameters in its own input parameters. If you navigate to a view, there is no page navigation and the navigation action is responsible for delivering the target view's parameters.
pturmel -- YF12901
If you throw a nav bar in the Perspective config page at the top and you set there lets say Tank1, Tank2, Tank3, and you want to change the background color of the nav bar item based on the tank that got clicked, yeah you could pass a param from one view to another and use that to make the logic work, however, if I go straight to the url and change the number, how the view knows that the param change when there was not click that occurred to pass a param?
I think that the system object might expose the url parameter? It does have exposed the query parameters (urlParams | name is confusing because they are not url parameters but rather query parameters) but not the URL parameters.
That would be a use case.
The canonical method is to use page messaging and message handlers to pass information from docks to main views and vice versa. Or place global values in custom session properties. The latter is convenient, but can be challenging when you wish to support multiple independent open tabs.
I created the pageVarMap() expression function and related script functions specifically to make cross-view, tab-independent management of variables easier. (Part of my free Integration Toolkit 3rd-party module.)
pturmel
Thanks so much for the conversation. Marking this as solution.