Friday, December 15, 2017

SPFx 1.4 brings automatic CDN deployment option!

Reading the latest release notes, it was a bit hard to find and to understand fully but here is what I got from it so far:

Starting from SPFx 1.4, there will be a new setting in the package-solution.json file.


Basically, when this feature is turned on, building a produciton package will no longer force you to specify the target CDN and manually host your files there.

Instead, all of these assets will go into the .sppkg file, and when deployed into SharePoint, they will be automatically uploaded to a CDN-enabled library either in your app catalog or - if you enabled it - another pre-designated CDN location.

The benefits are obvious:
That means smaller dev teams or vendors don't have to worry about keeping a CDN up to host their files.
Also, you won't have to worry about uploading and managing these files yourself.

The disadvantages for vendors like us are also clear:
We will have no control over the CDN, meaning - again - any minor change in code would have to result in a new package being built, published, sent to customers and installed before they will see any fixes applied.

While that was how we did things for years in the full trust world, in the ever-changing fast pace apps/add-ins world I am not sure if that is a viable option anymore.
Changes are being rolled to SharePoint continuously. Admins no longer have control on when updates are being installed. And so - our frequently have to update our code to work with these changes and adapt to new features on a regular basis.
Having our own CDN allows us to do just that - push updates to our CDN on a fast ring and production releases and our customers could be happier.

So, it is exciting to see this as an option, even though I probably won't be able to use it in the real world.

What do you think?

Tuesday, December 12, 2017

SharePoint REST API double encoding field internal names when using $expand=FieldValuesAsText

This is a simple bug I found when building one of our products while it was used by a French speaking customer...

He simply created a column with a french name that had some special characters, for example: "Français"

So, the letter ç was encoded when creating the column's internal name, which is what you'd expect. The column's internal name was: "Fran_x00e7_ais"

When making REST requests to SharePoint to get items, query items, or anything you like - you would get the item field value under this internal name - gain, as you would expect.


If you wanted to get the values as text and used the $expand=FieldValuesAsText in your query (or /FieldValuesAsText if getting a single item) - SharePoint returns something very different.

The value for this column would be set in "Fran_x005f_x00e7_x005f_ais", which is basically a double encoded version of the real internal name: "Fran_x00e7_ais"

I couldn't find a solution for this problem besides hacking it, so now I hard coded updated my code to replace _x005f_ with _ when looking for field values as text...

I'll report this issue but since changing it would potentially break so many existing applications I doubt it would be fixed any time soon.

So for now - keep that in mind, and let me know if there is a better way to finding out the field name that this REST API uses!