角色UI路由器在URL更改时不会获得查询参数

时间:2022-06-01 11:15:59

I've got a collection page with a navigation on the left and a bunch of records on the right. Each navigation item corresponds to a record. I want the user to be able to click a nav item on the left and then scroll to the record. Plus the nav item and record should have a 'selected' state.

我有一个收藏页面,左边是导航,右边是一堆记录。每个导航项对应一条记录。我希望用户能够单击左侧的导航项,然后滚动到该记录。此外,导航项和记录应具有“选定”状态。

The URL /stuff/4?selectedRecord=5 should get me all the records of collection id 4 and select record nummer 5.

URL / stuff / 4?selectedRecord = 5应该获取集合ID 4的所有记录并选择记录nummer 5。

I got this working with ui-sref on my nav/record items, and the state provider below. When I click on a nav item, the url and states change.

我在导航/录制项目和下面的州提供商处使用了ui-sref。当我点击导航项时,网址和状态会发生变化。

But when I change the url from /stuff/4?selectedRecord=5 to /stuff/4?selectedRecord=6, nothing happens. No $stateChangeStart is fired...

但是当我将url从/ stuff / 4?selectedRecord = 5更改为/ stuff / 4?selectedRecord = 6时,没有任何反应。没有$ stateChangeStart被触发......

$stateProvider

    // The stuff index: /stuff
    .state('stuff', {
        url: '/stuff',
        abstract : true,
        templateUrl: 'app/stuff/stuff.html' // wrapper
    })

    // Stuff detail page.
    .state('stuff.detail', {
        url: '/{stuffId}',
        templateUrl: 'app/stuff/stuff.detail.html',
        controller: 'StuffDetailController'
    })

    // Stuff detail page with a record selected
    .state('stuff.detail.selectedRecord', {
        url: '?selectedRecord'
    })

This is my sref nav item, which works:

这是我的sref导航项,它有效:

<li ui-sref="stuff.detail.selectedRecord({selectedRecord:record.id})"
        ui-sref-active="selected">Works</li>

Edit: The exact same code works if I change the url of the selectedRecord to:

编辑:如果我将selectedRecord的url更改为:完全相同的代码有效:

url: '/select/:selectedRecord'

1 个解决方案

#1


2  

The issue here is, that the url (url: '?selectedRecord') defined with question mark at the beginning is the weakest choice for regex... so, if you could have the url e.g. like this:

这里的问题是,在开头用问号定义的url(url:'?selectedRecord')是正则表达式最弱的选择...所以,如果你可以有url例如喜欢这个:

- /stuff/4/?selectedRecord=5  // see the '/' before '?'
- /stuff/4/?selectedRecord=6

all will work. In fact, there could be anything, just to help to distinguish that the previous url part ( url: '/{stuffId}') has been already evaluated.

一切都会奏效。事实上,可能有任何东西,只是为了帮助区分先前的url部分(url:'/ {stuffId}')已被评估。

In this plunker, this updated url defintion:

在这个plunker中,这个更新的url定义:

.state('stuff.detail.selectedRecord', {
        url: '/?selectedRecord', // the ? is preceeding with /
        ...
    })

there could be in fact any other char or combination... just to help to find where the sub state url does start. (could play around here)

实际上可能有任何其他字符或组合......只是为了帮助找到子状态URL的起始位置。 (可以在这里玩)

#1


2  

The issue here is, that the url (url: '?selectedRecord') defined with question mark at the beginning is the weakest choice for regex... so, if you could have the url e.g. like this:

这里的问题是,在开头用问号定义的url(url:'?selectedRecord')是正则表达式最弱的选择...所以,如果你可以有url例如喜欢这个:

- /stuff/4/?selectedRecord=5  // see the '/' before '?'
- /stuff/4/?selectedRecord=6

all will work. In fact, there could be anything, just to help to distinguish that the previous url part ( url: '/{stuffId}') has been already evaluated.

一切都会奏效。事实上,可能有任何东西,只是为了帮助区分先前的url部分(url:'/ {stuffId}')已被评估。

In this plunker, this updated url defintion:

在这个plunker中,这个更新的url定义:

.state('stuff.detail.selectedRecord', {
        url: '/?selectedRecord', // the ? is preceeding with /
        ...
    })

there could be in fact any other char or combination... just to help to find where the sub state url does start. (could play around here)

实际上可能有任何其他字符或组合......只是为了帮助找到子状态URL的起始位置。 (可以在这里玩)