4

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?

  • Storing the complete data on SPFx web part property pane is not a good option. The purpose of property pane is to hold the properties configuration required by the web part. Also till now, I never came across situation where the property pane configuration is can be retrieve after deletion. Also note that, user with right permission have access to property pane. I still need to dig on permission part, but for sure, read users doesn't have permission to edit property pane properties. Finally I wont recommend you to save data on Property pane. – ThinkB4Code Jun 27 '17 at 14:36
4

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.