[Feature] Ability to configure Datasource Location

[bouncehead13]

Intro

Similar to ability to configure icon, placeholders, and allowedPlaceholders in the ComponentDefinition, it would be valuable to also modify the Datasource Location of the rendering using the code-first approach.

Use Case

By default the renderings Datasource Location is set to

./Page Components|/sitecore/content/<app-name>/Components/<comp-name>

In SiteCore

Requesting the ability to extend that and allow defining a custom path in addition to the defaults. It is valuable to create a custom path to hold any collection of components and add that path as an option to the DataSource Location.

Example

The new ComponentDefinition could look something like

interface ComponentDefinition {
    ...
    ...
    // path to a sitecore folder to enable the component rendering to pull from
    dataSource?: string;
}

[anastasiya29]

The ComponentDefinition interface is part of the manifest API, which is intended for use in Disconnected Mode only. It is intentional that Disconnected Mode doesn't support custom Datasource Location because this mode is not Sitecore-aware. It does not know what your Sitecore tree looks like, and it definitely wouldn't know what to do if you used a Sitecore query in that field. The manifest API is not a complete replica of everything that can be done with Sitecore items in Sitecore. When you've reached the point of needing advanced functionality like this, it's time to switch to Sitecore-first.

[bouncehead13]

@anastasiya29 I appreciate you reaching back out. I'm a little confused on your response though, so lets continue the dialog and maybe you can help clarify.

I understand your methodology that the ComponentDefinition interface is for local manifest. However, I find that contradictory as there exist 7 properties, listed below, that are SiteCore-aware and not for local development.

• icon
• defaultWorkflow
• renderingId & templateId
• displayFieldEditorButton & fieldEditorFields
• insertOptions

If these fields are directly tied to the SiteCore instance you are deploying to, then the proposed dataSource would follow similar principles. The manifest would see this new field and package it into the sitecore-import.json under the renderings section.

Why do you feel dataSource is in a different category than the above fields, which are deployed to SiteCore to configure the renderings?

Our organization does not have a dedicated SiteCore team to support the main Web Development team, so we rely on Code-First. Without the option for a custom path, we are limited to using only the auto-generated default <app-name>/Component/<comp-name>.

[anastasiya29]

@bouncehead13 Hey Matthew, It's the Datasource Location's need for tree-awareness that's the issue.

Whatever is created via the manifest API is ultimately imported into Sitecore. The fields that you listed - yes, you're right, those are Sitecore fields, - but as far as the manifest and the content import are concerned, they are arbitrary fields because the import just copies over the raw field values. And regardless of the field values, it doesn't affect the tree structure of the content import.

On the other hand, Datasource Location is different because it would require the importer to create Sitecore items in dynamic locations. For example, let's say your component definition had:

export default function(manifest) {
  manifest.addComponent({
    name: 'MyComponent',
    fields: [
      { name: 'heading', type: CommonFieldTypes.SingleLineText },
    ],
    datasourceLocation: `./Page Components|sitecore/content/xm-marketing/Components/CardComponent`,
  });
}

and your route yaml file had:

placeholders:
  jss-main:
    - componentName: MyComponent
      fields:
        heading: Welcome to Sitecore JSS

If you run jss import -c, the importer would not know where to generate the datasource item for the instance of MyComponent on this route. Should it look for a "Page Components" item or a "sitecore/content/xm-marketing/Components/CardComponent" item? What if those items doesn't exist? This creates the potential for the importer not being able to import all content. The other fields you listed don't have this concern.

I hope this explanation clarifies the difference.

[bouncehead13]

@anastasiya29 I think I understand where the confusion and disconnect between our ideas is coming from. Main reason, the name "datasource" is overloaded.

I think the datasource you are referring to is on the actual SiteCore item. What I mean by that is you create a new Item based on some Template and it references a datasource that populates those Template fields.

The datasource I'm referring to, and apologizes for not being more clear, is the datasource on the Template Rendering under the "/sitecore/layout" section in SiteCore. This datasource is used in the Experience Editor to display a modal to add a new/existing Item on the page. Think of this datasource as possible folders to store/search for respective Items.

To put this into an example, this rendering datasource tells SiteCore to show these 2 folders in the Experience Editor.

./Page Components|/sitecore/content/<app-name>/Components/<comp-name>

Nothing should change for default behavior Items/Components you create in the Route yaml file (as in your example), those automatically get created in the "Page Components". Similar to Items/Components that might get referenced by { "id": "some-item-id" } get created in the same folder path. Those are unaffected by this proposed change.

This new datasource, better named renderingDatasource, can be used during import to copy over the raw field value. It would not drive any pipeline on where to create the components during import.

I'm hoping this adds some clarity. I understand this is definitely a large ask, and probably needs more discussion, but could potentially have a big impact to Code-First driving configuration within SiteCore.