Disconnected mode not injecting the correct data in my component

[thany]

Description

So in /data/routes/en.json I've added the data that is supposed to come from Sitecore:

{
  "id": "home-page",
  "name": "home",
  "placeholders": {
    "jss-header": [
      {
        "uid": "64c2920a-deaf-4272-81fb-11a17d41b5b2",
        "componentName": "Breadcrumb",
        "fields": {
          "items": [
            { "href": "/", "title": "Home" },
            { "href": "/page", "title": "Page" },
            { "href": "/page/page", "title": "Sub page" },
          ]
        }
      }
    ],
  }
}

And then I've created a definition for this component in /sitecore/definitions/components/Breadcrumb.sitecore.ts:

import { CommonFieldTypes, Manifest } from '@sitecore-jss/sitecore-jss-dev-tools';

/**
 * Adds the ContentBlock component to the disconnected manifest.
 * This function is invoked by convention (*.sitecore.js) when `jss manifest` is run.
 * @param manifest Manifest instance to add components to
 */
export default function Breadcrumb(manifest: Manifest): void {
  manifest.addComponent({
    name: 'Breadcrumb',
    templateName: '',
    fields: [
      { name: 'items', type: 'Breadcrumb Items', source: 'Breadcrumb Items' },
    ],
  });
}

When I inspect what's being injected into my Breadcrumb component, it is nowhere near the json I put there. It's the correct number of items, for some reason, but each item only has:

displayName: "Breadcrumb-1-item-0"
name: "home-jss-header-Breadcrumb-1-item-0"
template: "Breadcrumb-items-Item"

Which is not correct. Not only is my data missing, it has also magiced up more data that I mustn't have in my component. We shouldn't be injecting superfluous extra data into anywhere - who knows what will happen. But more importantly, where's my data??

I've also tried wrapping each object into a value, I've tried every CommonFieldType. It always produces these weird objects with properties I never asked for. I even tried adding a template:

manifest.addTemplate({
  name: 'Breadcrumb Items',
  fields: [
    { name: 'href', type: CommonFieldTypes.SingleLineText },
    { name: 'title', type: CommonFieldTypes.SingleLineText },
  ],
});

Next to the component definition. Because idunnolol I have no idea what I'm doing because there's no full reference to JSS. I feel like I'm flying blind without any type of proper documentation that isn't an arm-grabbed collection of examples and loosely-described somethings.

So how do I deal with this? Where and how do I tell JSS to return those breadcrumb objects that I specified in en.json? Clearly it reads that file, or it wouldn't know to inject the correct number of items.

It's working fine for standard item types, I'll have you know. So there doesn't seem to be a broader issue with our setup.

Additional information

No response

[art-alexeyenko]

Hi @thany ! To walk through a couple of points:

 but each item only has:

displayName: "Breadcrumb-1-item-0"
name: "home-jss-header-Breadcrumb-1-item-0"
template: "Breadcrumb-items-Item"

These are standard fields, it's expected they are added. We can probably drop adding displayName, but items in Sitecore do require a name and a template. Manifest data can be used for disconnected mode, and it can be deployed to a Sitecore instance - and JSS won't be able to create items without a name or a template.

But more importantly, where's my data??

Right! The whole manifest system is tightly tied to Sitecore's data model with items, fields, templates etc. Different field types work differently (single-line text would be processed differently, to, say, multilist). So when you specify a field type in

 fields: [
      { name: 'items', type: 'Breadcrumb Items', source: 'Breadcrumb Items' },
    ],

you need to refence a known field type so that Sitecore or manifest API would know how to parse it.

From your description I believe you need to have a data source for the Breadcrumb component, that has a few subitems with href and title data.
In Sitecore this can be achieved if your datasource item (Breadcrumb) has a multilist (CommonFieldTypes.ContentList) field that references other items where you take href and title from (this would be your site pages, I assume).

So the definition you need would look kind of like this:

{
  "id": "home-page",
  "name": "home",
  "placeholders": {
    "jss-header": [
      {
        "uid": "64c2920a-deaf-4272-81fb-11a17d41b5b2",
        "componentName": "Breadcrumb",
        "fields": {
          "items": [
            { "id": "home-item-id"},
            { "id":  "content-page-1" },
            { ....etc.... },
          ]
        }
      }
    ],
  }
}

where the id fields are the IDs of items under /data/content, located it yml/json definitions.
For an example you can check how styleguide items are organized in nextjs+styleguide sample. See Styleguide-EditFrame or Styleguide-FieldUsage-ContentList in \data\routes\styleguide\en.yml, with how the components themselves read data from content lists.
You can also check general Sitecore documentation for its data model, like the one here: https://doc.sitecore.com/xp/en/developers/90/sitecore-experience-manager/the-template-field-template.html

[thany]

I don't have anything in data/content. What kind of format is expected to be placed there? (and don't say yaml/json again please, because that's a bit too broad) And also what are the files expected to be called?

Currently from your explanation, I would expect items there to have the exact format of a breadcrumb, and filename being an ID.

So in, for example, data/content/349837498723.json:

{ "href": "/page", "title": "Page" }

And then in the definition I would place that { "id": "349837498723" } same as you suggested.

Is this correct?

[art-alexeyenko]

The files under data/content are item definitions and they are expected to have an id (not a GUID, but a friendly name in this instance -for disconnected mode usage), a template and field definitions, in this format:

It's best to install the nextjs + nextjs-styleguide sample app to see examples with the full structure.

[thany]

The examples are too restricted, and not as custom as our situation. And maybe I didn't make it clear enough, but the data that I need(ed) to pass through, is completely custom (at least from the Sitecore point of view - they are fairly standard from our end actually). The disconnected proxy should completely "hands off" off data it doesn't understand.

Besides, examples should not be taken as a single source of documentation. I would need proper in-depth documentation and API references, which do not appear to exist.

[art-alexeyenko]

I apologize, I haven't checked discussions in some while.

There is a how-to doc for scaffolding a new component (with data) here:
https://doc.sitecore.com/xp/en/developers/hd/210/sitecore-headless-development/create-a-new-component-in-a-jss-next-js-app-using-the-code-first-development-workflow.html

and there is a reference for manifest API in here:
https://doc.sitecore.com/xp/en/developers/hd/210/sitecore-headless-development/jss-manifest-api.html

If you find something is missing - please let me know- I'll register a doc request to extend these or add some new docs.

The disconnected proxy should completely "hands off" off data it doesn't understand.

The app needs to be strict with disconnected data and needs to understand everything: the routes, the fields, the placeholder, etc. It is intended to emulate the Sitecore route structure and, to be able to be imported into Sitecore. If there's irregular data in there, there are bound to be conflicts when the app is deployed, or when the app is connected to Sitecore (components won't be able to read data from Layout Service correctly).

That is true for the usual component flow in JSS. We are currently working on "bring your own components" functionality - that will allow using "disconnected" components with Sitecore (i.e. components that do not use item/layout data as props and would be added to any place in a page, when working connected.).

[art-alexeyenko]

Closing this due to inactivity.
BYOC logic has been introduced JSS 21.4 and allows using components without tying them to Sitecore data.