sprLib.list().cols() alignment with sprLib.list().items() returned column names

[DavidPratten]

My use case is about handling empty lists. It would greatly simplify some code if I didn't have to treat the empty list case as a special one.

Is it possible to have a canonical list of columns that sprLib identifies as columns shared by sprLib.list().items() and sprLib.list().cols()?

I would like to use sprLib.list().cols() to extract the schema returned by sprLib.list().items(). However, sprLib.list().cols() has one view and sprLib.list().items() another?

At the moment the list of columns returned by sprLib.list().items() is only knowable by introspection of the result which fails in the case of zero items.

Thanks

David

[gitbrent]

Hi @DavidPratten

Thanks for the feedback. This is a topic that's not well documented or discussed.

The List API docs indicate that calling list().items() without any listCols will return the same results that the SP REST API provides for consistency (a "select *" basically). My thought was consistency is paramount, plus anyone who calls items without any args is likely someone who wants everything, possibly even the metadata.

The list().cols() method will return a trimmed list of fields available, as most users don't want to see 3 different "Title" columns - it's junk to them.

Therefore, i'd propose the answer is that cols() is a subset of all the columns that exist, but it always contains a valid array of fields, so you could use this call to answer the question, "What columns can i query?"

ITEMS

COLS

[DavidPratten]

Thanks @gitbrent

Another dimension on this challenge. The way spRestLib transparently translates between user and lookup columns object format and the simple list format is a great time and effort saver. However this is part of the challenge and is a source of divergence between items() and cols(). E.g. When the Editor column per cols() is retrieved we have items() return 'EditorId'.

One idea would be to provide items().cols() that works with or without items in the list?

[gitbrent]

I see what you're saying.

There's some inherent mapping weirdness with column names just due to the SharePoint team's API implementation, legacy support, etc. that has to be dealt with by any kind of a wrapper library like this one.

I like the idea of taking the last step and providing a collection of names that are universal across the methods...

maybe adding a new option: items({ useColNames:true }) that would return all cols but with the same names cols() produces - e.g.: Editor.Id instead of EditorId

[DavidPratten]

OK, I see.

I was rather a fan of the flattening of the object returned for users and lookups to an Id.

However, I can see that going back to an object but without cruft would be OK, and even create an opportunity.

While we are here, could we unify the handling of multiple select lookups so that both single lookup AND multi-lookup return Column.Ids with values [] for no value, [Id] for a user or single lookup, and [Id,Id,Id] for multi-select. Marshaled and unmarshaled for get, create and update.

This would also greatly simplify some of my code built on top of spRestLib.

Props to you by the way and a huge thanks.

David