Feature/csv export

[ellinge]

Tried out creating a export function as a custom component instead of the PR for having in the main library.

Have some issues fetching the dataSource-instance but at least one can export the current view.

        <pnp-export 
            data-columns="Title,Created"
            data-context="{{JSONstringify @root}}"
            data-instance-id="{{@root.instanceId}}"
        >
        </pnp-export>

Gives

Wanting to export all the data I tried to get a hold of the servicekey for the dataSource but can't seem to find it on the webservicescope/keys (or parent) so perhaps it's some kind of race condition?

[FranckyC]

That's encouraging! However, it seems I can't test it in the workbench as the option is disabled:

Also the data source is not exposed in the service scope shared to web components so it is the expected behavior. From a technical point of view data sources and internal services are instanciated in a child scope of this one, and after the components are registered.

[ellinge]

The button itself exports the current view if clicked. The other one is disabled since I cannot access the dataSource-instance currently(?) for a full export. Would be nice to be able to reuse the handlebars logic if extracting the columns from the context instead of the provided column names.

[FranckyC]

I get an empty csv when I click on the button unfortunately (I use the host workbench page)

[ellinge]

Ok, have not tried it in workbench mode unfortunently. As long as the context.data.items has the columns/properties sent in in data-columns it should work. Just raw managed property values currently. No handlebars templating… removed all of that for now.

But any ideas of exposing the dataSource and dataContext in a better way so one could fetch all items?

This is the current view export and a few lines below a match is done between object.keys and provided columns. Case sensitive?
https://github.com/microsoft-search/pnp-modern-search-extensibility-samples/pull/10/files#diff-a52114e9bb1cfbeadf1fd739293e13baf059eb6767aea3c3420c6a029bd6fab5R99

[FranckyC]

Exposing data source seems quite complicated due to the instanciation flow in the main component. The best we could do is to provide the search service itself. With the data source properties from context, you should be able to make the same query.

[ellinge]

Had a new look on this and even if exposing the the sharepoint search service there's a lot of "mapping" done for building the query with refinement etc which would have to be replicated from this.buildSharePointSearchQuery(dataContext).

Couldn't it be possible to move up the registrations of the IDataSource to the webpart scope instead of the child scope and expose the servicekey (in _webPartServiceKeys). If the _webPartServiceScopes and _webPartServiceKeys gets updated (if applicable / servicekey changed) after a dataSource has been established?

Then one could do the following in a custom component:
const dataSourceServiceKey = this._webPartServiceKeys.get(props.instanceId).DataSourceService;
const dataSourceInstance = this._webPartServiceScopes.get(instanceId).consume(dataSourceServiceKey);

Is it otherwise possible to somehow lazy load / import the chunk pnp-modern-search-sharepoint-search-datasource to create its own instance of the IDataSource?

Had an idea for another extension which perhaps would need this as well. Being able to create a separate query which fetches filter values to use for a search results web part (there's a column in another list which should be used as a filter when a status is set in another column). In a way a "join"/subquery without having to create a connection between two search result webparts (a.k.a parent / details). Instead, it's more of a hidden refinement but the filter values are based on another query instead.

[wobba]

If we moved the datasources to a separate npm package, that would make it easier perhaps? The we wouldn't need to pass the provider context. Unless you see some benefit of doing so like picking some settings from the web part.

[ellinge]

I think there are some internal dependencies from the webpartcontext. Such as manifest.version. Since IDataSource is a shared interface and there’s a similar approach for the TemplateService it would be easy to fetch an existing/current instance this way. I think the issue is, disregarding the childscope, that the datasource is set in the render for the search results web part but the webcomponents are initialized earlier (a.k.a the TemplateService-key set). But updating them in case of a datasourcekey change shouldn’t be an issue? If I remember correctly there’s even a lastDataSourceKey-variable to detect changes for…

[roldengarm]

Very interesting discussion! One of our customers is requesting an export button too on the search results. I've been following the original discussions to add this ability to the PNP Search Results Web Part, which was rejected, as it had to be built as an extension.

The main blocker seems to be that the data source with all results is not exposed to the web component, correct? Is there any solution for that?
I like @ellinge 's proposal to expose the data source as a service key, and have the ability to respond to data source changes; I think that would solve the problem.

@wobba any update on this please from your end?

One solution/workaround I'd have in mind is to re-do the query from the custom web component. Not ideal, but it should be possible, assuming the web part properties like queryTemplate are available in the web component.
But ideally the dataSource is exposed to the web component.

[wobba]

I have no update nor plans to implement this myself in the near future.