React-admin: List component does not update when filter property is updated

[kara-todd]

What you were expecting:
When dynamically updating the List filter property using a redux action the list data should immediately be updated.

What happened instead:
The list data is delayed in updating creating a confusing UX.

Steps to reproduce:
* CodeSandbox and demo
1. Sort by ID to generate query string params
2. Select "Group A" from the dropdown (no change to list)
3. Select "Group B" from the dropdown (list is now filtered by "Group A")

If query string params are not present an error is thrown to the browser console Warning: Missing translation for key: "Cannot read property 'toLowerCase' of null".

Other information:
I think this is related to the shouldUpdateComponent function in the ListController it seems like perhaps just adding the filter property to this list could fix the issue. However, I wasn't sure if it was intentionally excluded for performance reasons...

I think this stack overflow issue has the same root cause.

Environment

I have replicated this with two environments:

• React-admin version: 2.4.0, React version: 16.5.2
• React-admin version: 2.7.2, React version: 16.8.3

[kara-todd]

Our reason for wanting this is that we are using the filter parameter as a sort of "system imposed" filter that the user cannot directly change. Regular list filter parameters are still exposed to users and can be modified by them.

[djhi]

Thanks for the detailed report. This is indeed the same issue as in the StackOverflow question. Would you mind openning a PR?

[kara-todd]

Hi @djhi I'd love to... unfortunately, I'm having issues getting the test suite to pass even after I cloned down the repo directly. :(

I took the following steps:

1. $ git clone https://github.com/marmelab/react-admin .
2. $ make install (or yarn install)
3. $ make test-unit

All of my packages/ra-ui-materialui/* tests fail with Cannot find module 'ra-core'

Did I miss a step here?

[djhi]

Ah you need to build ra-core once in order to unit test the other packages. Try running make build-ra-core

[kara-todd]

@djhi I ran make build first and all my unit tests passed. 👍

I've opened a PR. Some of my end-to-end tests are (locally) timing out, but they shouldn't be impacted by the changes.

[fzaninotto]

for "system imposed" filter, use the permanentFilter prop

[kara-todd]

@fzaninotto I created a codesandbox fork using the permanentFilter prop but it also doesn't seem to be working as I would expect. Did I miss a step?

[fzaninotto]

sorry, it's called filter. https://marmelab.com/react-admin/List.html#permanent-filter

[Gonusi]

Using React Admin v. 2.92, I tried dynamically changing the filter prop on a List component, however ran into an issue:

The first time filter prop is set, it does not reach data provider. Then when you turn them off, data provider receives correct filter from previous step, even it "undefined" passed as filter prop. So the sequence is like this:
1. -> Not filtered
2. Data provider successfully has filters props
2. -> Not filtered

The behaviour can be seen using this wrapper of List component:

const BoList = props  => {
    const [isEnabled, setIsEnabled] = useState(false);
    return (
        <>
            <div onClick={() => setIsEnabled(!isEnabled)}>Toggle Filter</div>
            <List
                {...props}
                filter={isEnabled ? { userId: '8f50eacf-758d-4848-b9f0-c238b78b10d6' } : undefined}
            />
        </>
    );
};

Very possibly I'm missing something simple...

[rinde]

Any updates on this issue?

I'm experiencing the same behavior as @Gonusi: the filter always lags one step behind. I am integrating with a calendar component and I want the filter to adjust to the period that is visible in the calendar. What I'm observing though is that the data that is loaded is the data of the previous period.

[nicgirault]

Same issue here trying to filter data according to the selected locale. Any plan to fix the issue?

[kara-todd]

Since there has been some recent comments here. I opened a PR a while back (#2926) but it's since fallen behind.

[djhi]

Sorry about this. It has been fixed by #3308 and I forgot to keep you updated.