Ours is a SPA app being built using Sitecore JSS. One of the pages has the requirement to show client info. But the actual client data comes from an API. But the content labels (like Description ,Email, Phone etc) should be maintained in CMS. What's the best way to do it? Is it a good paradigm to store these label info under gloabal content in Sitecore and return the data through an API call to front end?
2 Answers
JSS has a REST Dictionary Service for labels, button texts, etc.
As of JSS 11, the URL format is /sitecore/api/jss/dictionary/<app>/<language>/
(e.g.: http://JssReactWeb/sitecore/api/jss/dictionary/JssReactWeb/es-MX/ ).
you can use this service in your code directly to get the translated labels for the current language.
See the official documentation for more information: https://jss.sitecore.com/docs/fundamentals/services/dictionary-service
As usual, it depends. While in some cases using Sitecore Dictionary is a perfectly valid solution, based on my experience, it is best to store content labels on the rendering datasource item. You can group content labels to a Sitecore template section for better separation. In this case your labels will be part of the LayoutService output for your rendering.
This approach has the following benefits:
- Labels are experience editable. Note: It is possible to make dictionary items experience editable, but this requires extra effort and customization.
- You can use any field type for label text, e.g RichText. This is not possible out-of-the-box with dictionary approach.
- From the Sitecore tree structure it is immediately clear which labels are part of the page (if you keep your datasource items under the page item), while it takes some effort to find them in a dictionary. Note: You can also create folders in Sitecore dictionary, but still all dictionary items are stored in a central location, and when the website grows, it becomes tedious to manage them.
This approach would not fit though in case you need to share some label (e.g "Email") in multiple locations and want to have it "centrally" editable.