Cannot get item via getItem after a search

Hey guys,

We use search in filemanager widget using handlers.search config and handle clicking on items via on.onItemClick handler when creating filemanager instance.

When users click on item this.onItemClickHandler, it fires with id and event parameters. If there is no search we can get item via filemanager.getItem(id). But if items are shown in filemanager after a search, filemanager.getItem(id) returns undefined.

After small research it seems that webix populates its datastorage with the searched items but then resets them to root folder items only.

So the question is “How is it possible to get item after a search”?

p.s. couldn’t recreate this issue in the snippet because not sure if it’s possible to use dummy BE service with a route handlers.search there.

Thanks.

Hello @Dennis,

couldn’t recreate this issue in the snippet because not sure if it’s possible to use dummy BE service with a route handlers.search there.

We do actually have a snippet readily available that already features the use of the search handler: https://snippet.webix.com/yr2ybub4. I’ll try to use this example to convey my thoughts, you also might be able to use it to provide a related sample.

After small research it seems that webix populates its datastorage with the searched items but then resets them to root folder items only.

I don’t actually think that it’s the case. The search functionality is basically a filter, and calling the filter() method doesn’t alter component’s DataStore in any way. You are probably describing the way the dynamic branch loading works, as the needed branches will be loaded on demand.

So the question is “How is it possible to get item after a search”?

I am not quite able to reproduce the issue you are having (at least via the snippet provided above). As you can see from this snippet - https://snippet.webix.com/1cl7p3g5 (try looking up values on different levels of hierarchy, also note the DataStore pull) - you are unable to get the items that weren’t dynamically loaded already. As for the rest - the method works as expected after the search.

Could you please use the above snippets and try to reproduce the issue? I might be misunderstanding something, but I can’t really pinpoint the issue.

Hi @Dzmitry,

Thanks for pointing me to the snippet. I could reproduce the issue I was talking about. Please take a look at https://snippet.webix.com/o5e9hz8r.

I uploaded ‘stock…’ image file to newFolder. So if you’re on root folder and try to search ‘stock’ you should see that file. When you click on it onItemClick should be fired with the corresponding id. And the thing is getItem returns undefined for this id still. Also, I didn’t find ‘stock…’ image in data.pull. But getItem returns file if you go to newFolder → then back → then search ‘stock’ one more time.

Thanks.

Yep, I can see what you are talking about now. Basically, it seems that when you are performing a search with the search handler specified, you are essentially looking at the server response data, without that data being handled by the file manager component. The query result is getting parsed directly into the treetable component, which serves as a temporary storage for the search result.

The easiest solution in your case would be to call the getItem() method directly from the treetable view (you can access it by referring to its inner id of $$("table"): https://snippet.webix.com/4dv4yim2.

But getItem returns file if you go to newFolder → then back → then search ‘stock’ one more time.

This is happening simply because of the dynamic loading. As you visit newFolder, all the data inside of that folder is loaded to the file manager’s DataStore, and is accessible until a full reload. So, basically, one of the ways to avoid this issue altogether would be to forego the dynamic loading.

Hey @Dzmitry,

Your solution described in https://snippet.webix.com/4dv4yim2 works well! One difference is - in my case there is ‘files’ mode instead of ‘table’. Thank you for the help!

But there is one thingy with search and dynamic loading (seems) that onItemSelect doesn’t work for the same scenario: users on the root folder → they search for ‘stock’ phrase → they see ‘stock…’ image and click on it to select but onItemSelect is not triggered. I added the case to the snippet https://snippet.webix.com/kt3i8rxq. What could be a reason and how to get notified about a file after users select it in a search result?

Thanks.

Hey @Dennis,

Basically, the onItemClick event gets called by the views located inside of the filemanager component, which is why when you attach the handler to the filemanager itself it actually does work in this case, as the onItemClick gets called by the treetable view, not the filemanager.

The onItemSelect is different in this sense, since this event will only work with items that exist within the filemanager’s DataStore. This simply means that you will have to listen to the onAfterSelect of the treetable/treeview instead (since, as we’ve established earlier, the search data gets parsed directly into treetable/treeview).

Here is an example: https://snippet.webix.com/j8kj1585. Naturally, the same logic also applies to the “files” view.

hey @Dzmitry

Thanks! Your piece of advice really helped me and I could get item in a search “view”.

One thing that still looks broken is that right mouse click context menu doesn’t work for some search items if they weren’t added to the “main” (afaiu) store.

For instance, in https://snippet.webix.com/j8kj1585 snippet you can try to search for apex.jpg query for the same named file which is in One(2) folder. And if you right mouse click on it you’ll see the error.

How can that be fixed? I though about onAfterLoad handler but it doesn’t have mode and data parameters so I could manually add new data after search mode load…

Thanks.

Hey again @Dennis,

One thing that still looks broken is that right mouse click context menu doesn’t work for some search items if they weren’t added to the “main” (afaiu) store.

You are entirely correct, we have personally encountered the very same bug the last time we were talking about your issues. I don’t have a specific time frame for the release of the fix, but it will be out in the nearest future.

For now though, I don’t think there is currently any workaround that can be employed, since the whole context menu logic is based around file manager’s DataStore (which is why the context menu will only work for the loaded items), and some improvements in that regard are needed.

The only other way around is to entirely disable the context menu for searched items that weren’t loaded in yet: https://snippet.webix.com/goxn4q60.

@Dzmitry

If possible, please also try to fix the case where user cannot navigate to a found folder. In https://snippet.webix.com/goxn4q60, if I search for test and then click on 1st found folder called test, the file manager does not open it.

hi @Dzmitry

We have some important customers which need this “search” feature. I’d appreciate if you could provide the release when you can fix it and the date (or week) of the release if so. So we can provide the information to our customers in our turn.

Thank you for your help.

Hello @Dennis,

We have some important customers which need this “search” feature. I’d appreciate if you could provide the release when you can fix it and the date (or week) of the release if so. So we can provide the information to our customers in our turn.

Are you referring to the context menu bug that we’ve talked about last time? If so, I will need to double check to be able to provide you with any kind of an approximate time frame.

hi @Dzmitry,

Yep, I’m talking about the context menu bug for “search view” items. But also I thought that bug is related to one @olzhas described above. Could this bugfix fix also his case? I thought so because it’s something about updating “search datastore”.

Thanks.

Hey @olzhas,

I can confirm the bug, thank you for the report!

@Dennis,

Yep, I’m talking about the context menu bug for “search view” items. But also I thought that bug is related to one @olzhas described above. Could this bugfix fix also his case? I thought so because it’s something about updating “search datastore”.

You are right, we’ve also taken a note of the bug described by olzhas, since both issues are related to the same cause. Unfortunately, I can’t provide an approximate timeframe just yet. I will update you as soon as I get any updates regarding the state of the fix. Thank you for your patience.