Add status filter for KubeCRDs

[lalexander07]

This pr is to be able to filter by statuses (partner ask was specifically pod statuses) on WebXT Falcon's clusterfleet explorer headlamp plugin

How to test

Go to Pods, click on the filter, enter some status in the "Statuses" filter.

[illume]

Thank you for this.

I left a few notes about the html tags, and in a few spots where the translation might need attending (the old code didn't have a namespace... maybe it was buggy?).

Would you mind rebasing so there are no merge commits?

We do atomic commits with one commit containing a self contained thing. For the git comments, we follow the linux kernel style format. First subject line in imperative mood at 50 chars max starting with the context. Then more description if it's needed in the body 72 chars after a blank line.
eg.

frontend: StatusFilter: Add component to filter by pod statuses

Body goes here with extra if you need it in 72 chars per line... It facilitates 
resource filtering based on statuses with an autocomplete input field.
Works seamlessly with existing filters.

I haven't got around to testing it yet... but I will do that next.

[illume]

This needs to be added to the translation files. If you run the tests locally, I think it changes the files for you.

[illume]

I'm trying it out, and when I open the filters I get this message repeated over and over in the console.

Warning: Maximum update depth exceeded. This can happen when a component calls setState inside useEffect, but useEffect either doesn't have a dependency array, or one of the dependencies changes on every render.
    at StatusesAutocomplete (http://localhost:3000/static/js/bundle.js:27277:80)
...
    at SectionHeader (http://localhost:3000/static/js/bundle.js:26169:5)
    at SectionFilterHeader (http://localhost:3000/static/js/bundle.js:25843:5)

When I click on the input field this error happens, and it crashes...

Uncaught Error: Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.
    at checkForNestedUpdates (react-dom.development.js:23803:1)
    at scheduleUpdateOnFiber (react-dom.development.js:21835:1)
    at dispatchAction (react-dom.development.js:16139:1)
    at InputBase.js:412:1
    at invokePassiveEffectCreate (react-dom.development.js:23487:1)
    at HTMLUnknownElement.callCallback (react-dom.development.js:3945:1)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:3994:1)
    at invokeGuardedCallback (react-dom.development.js:4056:1)
    at flushPassiveEffectsImpl (react-dom.development.js:23574:1)
    at unstable_runWithPriority (scheduler.development.js:468:1)
checkForNestedUpdates @ react-dom.development.js:23803
scheduleUpdateOnFiber @ react-dom.development.js:21835
dispatchAction @ react-dom.development.js:16139
(anonymous) @ InputBase.js:412
invokePassiveEffectCreate @ react-dom.development.js:23487
callCallback @ react-dom.development.js:3945
invokeGuardedCallbackDev @ react-dom.development.js:3994
invokeGuardedCallback @ react-dom.development.js:4056
flushPassiveEffectsImpl @ react-dom.development.js:23574
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
flushPassiveEffects @ react-dom.development.js:23447
performSyncWorkOnRoot @ react-dom.development.js:22269
(anonymous) @ react-dom.development.js:11327
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
flushSyncCallbackQueueImpl @ react-dom.development.js:11322
flushSyncCallbackQueue @ react-dom.development.js:11309
discreteUpdates$1 @ react-dom.development.js:22420
discreteUpdates @ react-dom.development.js:3756
dispatchDiscreteEvent @ react-dom.development.js:5889
Show 21 more frames
Show less
console.js:213  The above error occurred in the <ForwardRef(InputBase)> component:

    at InputBase (http://localhost:3000/static/js/bundle.js:99503:83)
    at Input (http://localhost:3000/static/js/bundle.js:98717:82)
    at div
    at http://localhost:3000/static/js/bundle.js:65788:66
    at FormControl (http://localhost:3000/static/js/bundle.js:94262:82)
    at http://localhost:3000/static/js/bundle.js:65788:66
    at TextField (http://localhost:3000/static/js/bundle.js:120951:83)
    at div
    at http://localhost:3000/static/js/bundle.js:65788:66
    at Box (http://localhost:3000/static/js/bundle.js:138130:72)
    at div
    at http://localhost:3000/static/js/bundle.js:65788:66
    at Autocomplete (http://localhost:3000/static/js/bundle.js:83260:83)
    at PureStatusesAutocomplete (http://localhost:3000/static/js/bundle.js:27123:3)
    at StatusesAutocomplete (http://localhost:3000/static/js/bundle.js:27277:80)

[illume]

Note, I see the Statuses drop box is appearing on views without a Status column.

[joaquimrocha]

Hi @lalexander07 . Thanks for the PR.
I understand the need for filtering on status and we have had a similar request in the past for other columns.
Headlamp's SimpleTable uses the MUI Table within, which is a very simple table, meaning it's not easy to provide e.g. filter by column value.

Due to the space around the filter UI being limited, and given that other partners have asked for different columns to be filtered, I have been pushing back on adding more fields to the SectionFilterHeader.
We do have it in our backlog to replace the tables we use by a more advanced table that provides column filtering for "free". See #1646 .

Till we replace the table component, maybe we could have an alternative approach here: instead of having a dedicated entry for the status search, how about we use a search prefix? e.g. status:running would show only rows whose status column matches the value "running". This approach is also used in other popular apps like Slack.
We could add a button to the search input field (as an "start adornment" in MUI) to select any searchable column, so the users do not have to guess that searching by column requires a prefix, i.e. that extra button in the input shows a dropdown with the options "Search by: Status | Node | ...". This would also allow to combine search column values: status:running,node:my-super-node.

What do you think?

[illume]

Hrmm. The problem with the status:running approach is that it's not easily discoverable.

[joaquimrocha]

Hrmm. The problem with the status:running approach is that it's not easily discoverable.

Correct, but if we add that dropdown filter in the input, then it should fix that issue.
I have talked to @lalexander07 offline and this solution tackles the problem for them, while it is also a more scalable fix for us, so it feels like a good way forward.

[ashu8912]

One thing I noticed while testing this PR is that unlike namespace filter the queryParam status is not persisted on view change but the state still shows the updated values

[ashu8912]

Also the tile of this PR is a bit confusing to me, are we adding this to the CRDs, how??? Maybe changing it to something like adding status filter to views where we have the status column would make more sense