When a node type filter is active in the navigateComponent, when navigating the node tree previously filtered nodes disappear..
This is not easy to explain, here's a video of the bug in action:

I don't understand what is happening exactly, but I can confirm that this works in the "old UI".
Using Redux DevTools to debug this I can see a lot of removed nodes in the state of the ADD event but I'm not sure if that helps ;)

When there are a lot of (Document) Nodes on one level, this can significantly slow down the NodeTree. For this reason it can make sense to hide certain node types using the Node tree base node type.
Not reproducable in Neos 3.3 with UI 2.x and Neos 4.2 with UI 3.x
@bwaidelich do you still get this error?
Yes, unfortunately the issue still exists for me 鈥撀燽ut not when filtering for node types, but for custom presets.
Add some preset via Settings.yaml:
Neos:
Neos:
userInterface:
navigateComponent:
nodeTree:
presets:
'default':
baseNodeType: 'Neos.Neos:Document,!Neos.Demo:Chapter'
'legalPages':
ui:
label: 'Test Preset'
baseNodeType: 'Neos.Demo:Chapter'
...follow the "steps to reproduce" from above
We start using the custom presets for a current project and now I am affected of this issue.
I could sponsor a bugfix if anyone could do this in the next 2 weeks.
As already mentioned in the PR the general issue seems to be resolved but we have some glitches left.
So when you move a node inside another node the tree does not show that until you refresh the tree.
Or when you create a new node and the filter is enabled, the new node is also not part of the tree until you refresh the tree.
I would say we open a new PR for that. But it works much better than before. Thanks to @dimaip and @DrillSergeant 鉂わ笍
Do you want to continue @dimaip or should I start checking that out?
@markusguenther I can try to fix it on Wednesday probably, but please take over if you feel like you got the time and know how to fix it.
Basically the problem is quite clear: we render all metadata in backend using the default preset. I currently don't know how to fix it. Maybe we need to pass the currently active preset to all backend requests. Maybe there's an easier fix to just mask the issue (like I did in the other bugfix).
Thanks for the work so far and for caring to fix the last known issue.
Yes, thanks for taking care!
Could you elaborate on
Basically the problem is quite clear: we render all metadata in backend using the default preset
Which kind of metadata is that in this case and why is it dependent on the current preset?
Information about nodes, in particular node children.
After a first test in the NodeInfoHelper.php the actions work fine with the legalPages baseNodeType. So passing this information thru the class would be solver :)
So guess will check what we need to change here. And if this will be still a bugfix ;)
@dimaip Yesterday I did not find the right angle to tackle that. The quick test in the NodeInfoHelper solved the issue, but passing thru the information is not that easy I guess. As the most endpoints just use the flow query and the controller context.
So maybe adjusting the resulting flow queries are the solution.
But did not finish my investigation there yesterday. But in the end the baseNodeType is the root of all eval and we need to adjust that somehow.
Hope to find time soonish... if not maybe you have more luck on Wednesday.
Would be good to have this done before you do a new UI-release. In our current project the editors (more than 20 of them) will start editing content by the end of next week. It would solve a lot of problem for us if they could use the filter-presets. I can help testing. If sponsoring is needed, please contact me.
I'm giving it a try now, will keep you posted
Got it working, will push tomorrow with fresh brain
Unfortunately the bug still exists: When moving pages in a filtered view, the tree is empty after the drag n drop interaction