Error when trying to update `data` after deleting an item

[AdamFipke]

Description

In my use case, I have it so that when a file is deleted, it first shows a modal that says where the files are used. Upon clicking confirm, it will then call end endpoint to update references to said files and then delete the main file. After the endpoint completes successfully, I have the frontend re-fetch the new data (partially because I couldn't figure out how to update the internal SVAR filemanager state on the frontend) into the same state variable the Filemanager was initialized with (see code reproduction example). Upon doing so, the browser seems to crash "Cannot read properties of undefined (reading 'type')"

The way I've implemented it goes as follows:

• Use api.intercept("delete-files",...) to open the modal and return false to prevent default action
• Modal calls some endpoints and eventually deletes the file
• On success it re-fetches the data that's used for the data attribute for the Filemanager component

Code reproduction

I simplified a lot here. Goal is to demonstrate how re-fetching the data (after deleting an item) seems to cause the browser to crash.

https://snippet.svar.dev/react/uxI4MD2Q7

Full error message here:

Cannot read properties of undefined (reading 'type')
    at eval (https://codesandbox.svar.dev/node_modules/
svar-ui/filemanager-store/dist/index.js:529:16
    at k (https://codesandbox.svar.dev/node_modules/
svar-ui/filemanager-store/dist/index.js:528:13
    at Object.exec (https://codesandbox.svar.dev/node_modules/
svar-ui/filemanager-store/dist/index.js:785:17
    at T._execNext (https://codesandbox.svar.dev/node_modules/
svar-ui/filemanager-store/dist/index.js:375:35
    at T._triggerUpdates (https://codesandbox.svar.dev/node_modules/
svar-ui/filemanager-store/dist/index.js:359:17
    at T.setState (https://codesandbox.svar.dev/node_modules/
svar-ui/filemanager-store/dist/index.js:338:19
    at T.init (https://codesandbox.svar.dev/node_modules/
svar-ui/filemanager-store/dist/index.js:310:110
    at U.init (https://codesandbox.svar.dev/node_modules/
svar-ui/filemanager-store/dist/index.js:1100:20
    at eval (https://codesandbox.svar.dev/node_modules/
svar-ui/react-filemanager/dist/index.es.js:1762:9
Object.react_stack_bottom_frame
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:25989:20
runWithFiberInDEV
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:871:30
commitHookEffectListMount
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:13249:29
commitHookPassiveMountEffects
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:13336:11
commitPassiveMountOnFiber
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15484:13
recursivelyTraversePassiveMountEffects
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15439:11
commitPassiveMountOnFiber
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15718:11
recursivelyTraversePassiveMountEffects
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15439:11
commitPassiveMountOnFiber
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15718:11
recursivelyTraversePassiveMountEffects
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15439:11
commitPassiveMountOnFiber
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15476:11
recursivelyTraversePassiveMountEffects
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15439:11
commitPassiveMountOnFiber
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15476:11
recursivelyTraversePassiveMountEffects
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15439:11
commitPassiveMountOnFiber
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15476:11
recursivelyTraversePassiveMountEffects
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15439:11
commitPassiveMountOnFiber
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15718:11
recursivelyTraversePassiveMountEffects
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15439:11
commitPassiveMountOnFiber
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:15519:11
flushPassiveEffects
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:18432:9
eval
https://codesandbox.svar.dev/node_modules/react-dom/cjs/react-dom-client.development.js:17923:15
MessagePort.performWorkUntilDeadline
https://codesandbox.svar.dev/node_modules/scheduler/cjs/scheduler.development.js:45:48

[Natasha-eng]

Hello @AdamFipke ,

You can try two ways to delete item while preventing the default action.
In the first way instead of updating the data prop, you can use provide-data action to refresh the file tree (line 39).
Please che the example: https://snippet.svar.dev/react/vY7cDD8Lj

In the second way after deleting file on the server you can trigger delete-files action via exec method.
Also in the line 52 the delete-file action is detached to prevent infinite loop because it triggers the same intercepted event again.
Please check the example: https://snippet.svar.dev/react/XcazunfQX

[AdamFipke]

Hi @Natasha-eng ,

Sweet, using provide-data worked like a charm! I did also just want to say that the setup you guys have with being able to quickly create code snippets is fricken awesome! It's been very handy.

Apologies for not thinking on using provide-data earlier. I suppose I got confused reading the documentation since it sounded like provide-data was only to be used in tandem with request-data for lazy loading folder content, not updating the entire filemanager state. For instance, the provide-data docs state "Allows parsing data to the File Manager widget. The action fires after the request-data action, namely, when the required folder ID (for which data is requested) is received. This action is not triggered for updates through the data property." The "Allowsing parsing data to the File Manager widget" is a little confusing since you can also do that by passing the data attribute and the rest of the description makes it sound like it's for the Dynamic Data Loading example which specifically states that "The widget also allows loading data dynamically. To enable it, in the data array you should define the lazy field for the folders whose content you would like to load dynamically and tune your server so that the content of these folders is not loaded during the initial loading." So basically all references to provide-data makes it sound like it's only for the lazy loaded folders. Also I guess there's the example in the same guide just above where one loads data asynchronously (through the data prop) and I guess it seems weird from someone outside why you wouldn't be able to just load in new data through the same prop. Hence where I guess I landed here with this issue.

I couldn't find if the docs are open source (I would open a PR if I could), but I guess here would be a list of changes I would make to the doc pages:

data

• "The initial data containing all the files and folder structure data. Can be loaded asynchronously, but should not be updated once set (if you need to do that, such as if something outside of SVAR's File Manager updated/created/deleted a file, do so with the provide-data action).
• ideally would be renamed to initialData, but that would be a breaking change.

provide-data

• "Allows parsing data to the File Manager widget" -> "Sets the file and folder structure data in the File Manager. Useful for updating the File Manager data state after it's been initialized by the data prop."
• Under "parameters": "id (string) - (required) the ID of the parent of the provided folder (if any) that you are setting the data for. Providing an id of "/" (i.e. root) will replace all previous file and folder data with the given data" (bold is new)
• Personally, I would prefer it if it were named set-data since "set" feels a little more well-defined if you come from a React background (i.e. "this will replace any existing data with this new data"). "provide" sounds like it could only be doing an insert rather than a full replacement. This feels more pedantic though, and would be a breaking change, and so idk if it'd be worth it.
• In the "Examples" I would include a link to the Loading data guide

Loading data

• I would just include a small example of using provide-data to update the File Manager state. Basically with this example you gave earlier snippet.svar.dev/react/vY7cDD8Lj
  • "Note that by default, the File Manager will handle the file/folder structure state for you once initially loaded. You would only need to use the provide-data action if an external system or function were to update the file/folder structure and you wanted to update the state by passing the new data to the File Manager.
• Under Dynamic Data loading-> "The widget also allows loading folder data dynamically (i.e. load the data only when the folder is opened in the UI), which can be useful for very large file structures. [rest of article...]"

[Natasha-eng]

Hello @AdamFipke ,
Thank you for the detailed feedback and suggestions!
I apologize for not investigating the root cause of your error more carefully initially. The issue you encountered occurs because when you update the data prop directly, the File Manager's internal selection state still references items that no longer exist in the new data structure. This causes the mapping logic to fail when trying to access properties of undefined items.
If you prefer to update data through the data prop, you must also clear the selected items from the active panel. Here's the working example: https://snippet.svar.dev/react/MyeTycvcE

However, the recommended approach by our dev team is to handle updates through File Manager actions rather than directly mutating the data prop. You can trigger the delete-files action with additional parameters after your server-side operations complete:
https://snippet.svar.dev/react/RvuSlOUos
This way, the File Manager manages its internal state consistently without conflicts.

Regarding provide-data documentation we'll update the documentation to clarify that provide-data can be used to reload any branch at any time, not just as a paired action with request-data for lazy loading.