0

I'm working on migrating a legacy Sitecore site to JSS. In order to support the field types that they have in the existing site I have to support fields that do not conform to the predefined fieldTypes.

For example, I may get the following JSON for a component.

{
    "componentName": "legacy-component",
    "fields: {
        "FirstName": "Test",
        "LastName": "User",
        "Profile": {
            "Url": "http://example.com",
            "Title": "Profile"
        }
    }
}

However, when simply copying this data via a route into the manifest the data gets converted to the following:

{
    "componentName": "legacy-component",
    "fields: {
        "FirstName": {
            value: "Test",
            editable: "Test"
        },
        "LastName": {
            value: "User",
            editable: "User"
        }
    }
}

Notice that the value and editable fields are being injected (as expected), but the Profile field is being removed entirely. I've explored modifying the source and have some promising leads to be able to add the ability to essentially just pass through a json file for certain kinds of fields, while still supporting the conversion of common field types for the new component data that is added.

Ideally, I'm wondering if there's a way I can just pass through a copied json file to the manifest without it being modified in any way. The case this solves is FE developers working locally in disconnected mode without knowing anything about JSS or Sitecore, just the consumption of the data.

1 Answer 1

1

By default the sample apps use a disconnected version of Layout Service. Using this service is not a requirement for JSS apps, it is primarily provided as a convenience for developers. The convenience being that you are able to emulate the data you would receive from the actual Sitecore Layout Service while also preparing your JSS app for code-first deployment. In other words, you have a consistent API for getting started with JSS and eventually integrating with Sitecore.

You can absolutely still work in disconnected mode without using the provided disconnected Layout Service or even the manifest - it's just going to require some effort. If you want to mock the Layout Service data you know you'll be receiving from Sitecore, you might consider building your own service layer to do that. Earlier versions of the JSS sample apps did just that.

ugly pseudo-code: if (env === development) { fetchRouteDataFromLocalFile(); } else { fetchRouteDataFromSitecoreLayoutService(); }

If you're planning to use code-first deployment, which may or may not make sense for this scenario, you may need to massage your local route data into the format the manifest generator is expecting. Beyond that, your manifest component definitions wouldn't require any changes. And again, manifest generation is completely optional, you only need it if you are deploying code-first or using the disconnected layout service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.