Understanding the overhead involved with routes and definitions

Question

I'm enjoying JSS so far but have some general questions about what I perceive as "overhead" work involved in setting up the routes, component definitions and such.

If I want to add a component, this is my understanding of what needs to be done:

1. Create the component itself.
2. Add entries for the component and its fields to a data/routes yaml.
3. Create a Sitecore definition file for the component (ComponentName.sitecore.js)
4. Import the component to ComponentFactory and set it.

This means:

• We have similar sets of data repeated in the component prop types, the routes yaml, and the definition file.
• Anytime I want to modify a component (say to add a new field), I have to update those three files.
• Initial setup of the routes yamls could be very time consuming, manually filling out multiple pages'/routes' worth of data.
• The main interface for rearranging components and editing their data is a yaml file. Again, this seems potentially time consuming and tedious.

So, I guess my questions are:

1. Have I summarized this correctly? Am I over- or understating the amount of overhead?
2. Are there existing workflow suggestions to mitigate the overhead? (Code-first sounds like the best workflow to me, but perhaps Sitecore-first would help with this?)
3. Are there plans to automate some of this or otherwise reduce the complexity? Perhaps the definitions, for example, could be auto-generated from the yaml and/or component prop types?

And finally, I found this blurb on the JSS documentation site, but don't understand it:

The manifest is generated by taking the YAML or JSON manifest data files described previously and reading them, then adding them to a JavaScript API that generates the manifest. This means that you can replace the JSON or YAML files with direct JS API calls, should you wish to do so. The sample apps use the convention of the /data folder as a convention only - the actual manifest is created using the manifest source files in /sitecore/definitions/*.sitecore.js. These manifest definition files use helper libraries to crawl the YAML/JSON files and add them to the JS manifest object. If you wish to extend or replace the /data convention, that's entirely possible.

So...

4. Can you explain the above and whether there are some possibilities here around what I've been asking?

Sorry for the long question, and thanks in advance. I look forward to working with JSS as it evolves.

Answer 1

That's a lot of questions for one question :)

1) Your summary is roughly correct. A good way of thinking about the interlocking pieces is that the .sitecore.js component definition is defining your component's data schema, the .yaml an instance of that schema, and the React component the presentation of an instance of the schema.

Some of the data is a bit repeated, yes, but there's a reason for it aside from sloppy architecture. An early version of JSS relied entirely on PropTypes to define the data structure. Unfortunately, PropTypes doesn't support the kind of rich data structures Sitecore can and is quite messy to extract from, and that evolved into what we have today to enable supporting non-sample-grade development.

We've also played with inferring the schema from the content, but that also suffers from lack of metadata (is that URL value a text field? a link? a rich text field?). It's also subject to human error - we can validate that the content data follows a consistent schema, resulting in typos in content data not creating new random fields in Sitecore.

2/3) We are investigating ways to infer the ComponentFactory at build time because that is definitely a place that seems like it could be automated. That is however something that would be React-specific.

4) Sure thing. The manifest is a dynamic JS API, and the YAML files are just a handy convention that feeds them. If you want to change how the manifest is composed - or implement your own conventions, such as inferring components from route data using some non-generic rule set of your own, you can. See the files in /sitecore/definitions, especially routes.sitecore.js, where the logic is for parsing the YAML/JSON files and adding them to the manifest JS API. Our implementation in the sample apps is just that - a sample, which may not be one size fits all for everyone. So we left it flexible for extension.

We're always open to feedback, so happy to hear it if you've got more ideas.