SPFx Client Web Part - Store In Properties or List

Question

I'm trying to get to grips with the SPFx client web part. I've read examples of people creating "items" which are stored in the web part properties. This looks great. No need to provision a list, content type and the user doesn't need to move away from the webpart itself to create list items. Pop open a dialog from the property pane, present a form for the user to fill out and store items in an array in the properties pane. However, if a user spends a lot of time in creating these "items" and then the web part gets deleted from the page, isn't that all then lost and unrecoverable?

Until realising that storing items in an array in the properties pane was possible, I've been provisioning a content type and list and then referencing the list in the properties pane, then doing a simple rest call to get the items and populate the web part. If the web part is ever deleted, it can be added again easily and the list referenced with no lost content. It can also be repeated on multiple pages and reference different lists.

Can anybody confirm whether spfx client web parts when deleted from a page (modern or classic) can be recovered, with the properties pane values still in tact? if that's not possible, then surely storing content in lists has to be the way to go?

Answer 1

So, it depends. Let's take two examples - one is a list of events, the other is a list of links.

IMHO, an event has a lifetime outside the webpart itself. I would want to manage those events on their own, possibly view them separately, and so on. In that case, it makes total sense to have a list backing those events. You could still allow the creation of events in the webpart itself, but you would store them externally. I can add the same webpart on a few different pages and show the same events, etc. So I would probably store some metadata in the webpart (the ID of the list, maybe the eventCollection or something that I want to filter that list by when I display it, maybe some sort options, or possibly just the name of the view I want to use to query the list), but the actual events would be stored in a separate list.

Now, on the list of links, depending on your scenario, can really have a lifetime and management consigned to the webpart itself. If I delete the page, I want those things to go away. I don't need to look at them separately, I don't need to manage them independently, etc. In that scenario it makes total sense to store that information in the properties of the webpart.

As for your question, the webpart properties are stored in the page content, so you could restore a previous version of the page and get the properties that way (on modern pages only. Classic pages still store the data separately in the webpart properties table).