JSS 11.0: First impressions
From alpha to beta to technical review and finally: Release. Sitecore feels JSS is production ready, so we thought we'd start poking it with the old stick to see what's what.
EDIT: If you're interested in further reading on the subject, check out my series on building dynamic layout support for JSS.
I've had my eyes on JSS for quite a while, but due to blah blah excuses blah I haven't gotten around to trying it out, until now. Alongside the release of Sitecore 9.1, Sitecore also released the first production-ready version of JSS, the shining new 11.0. Seems as good a time as any to finally get around to it! So I sat down together with a collegue and did a little review work. This was done using react as the application template. How the below findings relate to the other application templates, I am not sure.
Installing JSS is a breeze. You simply install it via npm with the following command: npm install -g @sitecore-jss/sitecore-jss-cli
Once it is installed, all you have to do to get started is to set up a bootstrapped app, using the application template of your choosing. Currently React, Vue and Angular are supported. Let's assume our app name is testapp and we want to develop using react: jss create testapp react
When the app has been created it will by default run in disconnected mode, meaning it is not hooked up to any Sitecore instance. If you want to develop towards an actual Sitecore instance, you'll of course have to install one of those as well.
(Just to be clear, you don't have to start with the bootstrapped app, you can build your own app from absolute scratch if you prefer.)
JSS CREATE and Multi-site support
One of the first things we realized was that the bootstrapped app that is installed with the jss create command is more or less an example of what a JSS app can look like. For any kind of production application, I dare say you will be forced to modify or replace parts of the original app, as opposed to just building a layer of react components on top of it. What we found with the initial app was, among other things, that it does not offer support for a multi-site solution. Requests toward the layout-service (probably the most essential moving part of JSS) only take the current route and language into consideration, not the site. A very easy fix for this is simply to make the route handler (RouteHandler.js) send the current site along in query parameter when requests are made to the service. The code first workflow of JSS involves deploying files to the Sitecore instance, which are imported as items. The import takes no note of site, but deploys everything to the same content structure. This includes renderings, data items, dictionary items. The good news is that the import is configured in the usual Sitecore manner, via pipelines and processors. If you would like to make the import step site-aware and able to handle separate site structures, you can create your own processors to take care of this.
Another limitation is the use of a global layout. The initial app uses a global layout defined in a layout.js-file, not matter what layout you set on the sitecore item. In fact, the actual sitecore layout will point to a view file that is completely empty. If your aim is to create a large application supporting a lot of complex functionality and multiple sites, you might want to change this. And of course you can. The layout service will provide you with the ID of the layout attached to the item you are requesting, so you could build functionality for fetching this layout, resolving the layout component, and usethis as layout instead (I've done a whole series on this, check it out).
In essence, the bootstrapped app should probably be viewed as an example app rather than a complete boilerplate.
Besides the above, we had time enough to do small smoke-tests of authentication, experience editor support, server-side rendering, GraphQL and personalization. Below are some quick notes on these subjects:
- Authentication: If your app contains parts that should be privy only to logged in visitors, you can easily achieve authentication support using the SSC Authentication Service.
- Experience editor support: We performed some limited testing on this part by simply adding a text rendering to a route in the JSS application and opened this in the experience editor, which worked perfectly fine.
- Server-side rendering: When you run Sitecore in integrated mode, Sitecore uses SSR by default. You can also achieve it in a headless manner, with some configuration required.
- GraphQL: This is my first experience with GraphQL, and so far it seems very robust. It's a query language that you for the purposes of JSS can use to control which data is fetched by your components. The queries can be set up in different ways, either in code or on the actual rendering item. The only limitation I've encountered so far is that GraphQL is unable (perhaps by design, as it could be a potential performance issue) to handle arbitrary hierarchies, that is to say it cannot handle a tree of descendants where the number of levels is unknown.
- Personalization: Personalization works just as well in a JSS app as it does in a vanilla Sitecore app. A very interesting perk when it comes to personalization with JSS is that, since the data is fetched by API-calls, using CDNs to serve cached versions of your site is not a problem. As some of us are aware, this is not the case with classic Sitecore apps, where CDN caching and personalization does not play well.
That is about as far as we got playing around with this. Sitecore provides excellent documentation for JSS, so be sure to check that out if you are interested.
01 Jan 2019, by Bonny Nilsson |
Sitecore 9, JSS, React, Headless