Contentful json editor
How can we align CMS entry and React components? The first obvious reason is to take the component’s Content Type and use it for displaying a specific component, assigned in our code. How can you implement a nested list like this in the content model? I think it’s clear - we do it the same way as with a template by adding a field with references to other components.Īn example of Component Description in Contentful For example, a text item, apart from a heading and the text itself, may have a set of links, tags, social buttons, etc. Besides, it is possible to have a list of other child components acting as component properties. Some components might not have any properties at all if their appearance does not depend on user data. We can also assign some properties that change a component’s behavior or some of its internal characteristics. This might be some data that will be immediately visualized, like text or a picture. Then, we send this data as props to a React component of our application. In Contentful, we describe a component as an entry that has a certain data set. If you are using atomic design methodology, which sets up the hierarchical levels like atoms, molecules, organisms and templates, then organism are suitable candidates for implementing them as components. First of all, it must be an isolated module in terms of design. It must have certain properties, so that we could use it for creating pages. Our cross-functional building block is a component. The key idea for solving out problem is mapping React components to objects stored inside CMS.
If necessary, we can add other template types here, thus adding more functionality to our application. We are just returning the specified components one by one. Standard template display is rather trivial. This is exactly where our CMS users will be forming a list of components to display on the page.
Our standard template has title, content and config fields, but at this moment the only field that matters is the content field, which has a ” References, many” type and a limitation on the type of used entries. Right now, we only have one type of a template, but we plan to add more in the future. Now, let’s take a look at renderTemplate. Likewise, selectTemplate returns an object, containing Content Type of the template in the templateType field, and the data stored inside of it is returned in the data field. Of course, in out case we only have one image, that’s why we retrieve the first element of the array. The selectImages function returns an array of objects, containing url and the name of the image file.
#Contentful json editor code
We will take a look at their code later, but for now it’s enough to know that these functions retrieve the necessary data from the nested fields. It is convenient for us to keep such selectors in a separate file, since we’ll have to access these functions permanently. Here, you can also see two helper functions: selectImages и selectTemplate.
Naturally, this function is asynchronous as it sends a request to Contentful server. The values that we are inputting in content editor while filling a page with data in Contentful will be accessible to us as fields of customPage.fields object. Here, we are just uploading the data with the help of getEntry and organizing them in a way that is convenient for further usage. The code of our page will look as follows. By now, we have already created a page in our CMS that has a standard template and a few components with the following types: ” Component: Description” and ” Component: Quote”. So, let’s assume that we will have a page called /leaders, and for a start we will create a corresponding file in pages folder. Note that all the changes made inside content editor will be accessible with PREVIEW_TOKEN, and only after the publication you will be able to access them with the help of DELIVERY_TOKEN, which we will utilize for showing the changes to the real users. You can find the values for SPACE, DELIVERY_TOKEN и PREVIEW_TOKEN you can find in the menu Settings > API Keys. The reason why we we wrote the import in CommonJS style is that we are going to use this file not only in the browser but also for the application server, which we will write on our own using NodeJS when we need to add dynamic routing. Don’t pay attention to the lines that are commented out for now, we will need them later.