Column naming convention with spfx & search

Question

I want to retrieve data from a SharePoint list, at the same time I want to retrieve data from web api in my spfx webpart. So basically what I want is to have a unified component that can just connect to either the SharePoint list data structure or the web api. Now to name my columns in my list, do I just name them things like: userType, userLocation, userRole or do I need to prefix the names with my company/solution name, something like: cbaUserType, cbaUserLocation, cbaUserRole.. if I do that in order to make it easy for myself when it comes to SharePoint search, do I need to change the web api as well to reflect the same naming standards? How do people handle naming fields when they need to use them in SPFx web parts? Or do I need to just get the data from the backend api and map it to my property names in code?

Any hint is appreciated.

Answer 1

You can name your columns in SharePoint as you please, and they will work the same. However, there are some things to note that will make your life easier when it comes to development, troubleshooting and maintenance of your solution.

First of all notice that for column names there are basically two for each column: an internal name and a display name. The internal name is used by "backend" SharePoint as a fixed reference to that specific column. It is not possible to change the internal name. The display name is what is shown in the UI to users on lists, new/edit forms and so on. The display name can be changed as many times as needed. For your solution all you http request will deal with the internal names.

You can set the internal name and display name for a column programmatically, eg. by PowerShell. Through the UI you set the internal name when you create a column, and once you update the name of the column the new updated name will be the display name (before that display name and internal name will be the same).

Its advisable to make the internal name simple yet descriptive and also pointing to the specific solution that they are used in. Furthermore, it is advisable to avoid spaces and special characters in the internal names as they will translate into Unicode. If we take your own example of "cbaUserRole" I think that makes sense if the "cba" part is a reference to either the solution or something else that would make yourself and others working on that tenant aware of what those columns are used for. The display name then of course would be "User role" in this example.

Before starting development on your solution, I would start up a little "column cheat sheet" noting down what you create of columns, what type they are and which managed properties they are mapped to. It could look something like this

A sheet like that will help you now, in the future when bug fixing, and your co-workers will be happy for an easy overview of what is going on :)