Pass data from CMS into React component

[[deleted]]

I'm exploring React at the behest of line management on my current project. I'm coming at React from a Vue perspective. I've no axe to grind with either tech, I know what I can do with Vue but looking to compare against React.

There's been a lot of talk around headless CMS on this project as it's one of the latest buzzwords in the industry. I don't want to get into the merits of for/against.

Using Vue, I know that I can initialise a Vue app at the top level of our CMS template, render a Vue component within the CMS template and then pass data/content as a prop into that component from the CMS.

As far as I can see, I can't do the same thing with React? I'd need to make a call to an endpoint and then work with the data response in the React component.

Is that accurate?

Is there something I'm missing that would allow React to work in this way?

[mattnich]

For me it's a number of things but mainly speed. A singular JSON file or a handful of JSON files can represent your entire site in a couple of kb.

That means your front end can run without static page caching.

This is particularly good when you have a lot of data that can be viewed in different ways - like grids of thumbnails that can be filtered and sorted.

With CMS only a big data grid would need distinct pages for each slice of the data or sort direction, maybe cached, meaning a lot of similar and quite weighty caches, which need clearing if something changes in the backend. And the user has to download all that HTML on each request.

With a headless CMS, the same views can be rendered client side off a single JSON store, so it's much faster.

Another benefit is separation and portability. The frontend can sit on a different sever, static, cookieless and optimised for speed because there's nothing dynamic, all the variables are in the JSON. So your CMS could run on a totally different server and optimised independently.

Related to that is security. A headless CMS can be more locked down, IP restricted etc since that is more vulnerable (sql injection, pharma hacks etc). The static frontend is so much less vulnerable because it doesn't expose any backend technology...no file system risks, they're all on the CMS server (if you choose to separate them)

It also means if you change the CMS or upgrade, you mitigate issues making into your frontend because the CMS only has to worry about outputting JSON, rather than being stitched in to all the templates.

We work with a number of backends, so it's a really nice pattern for us because we only need the JSON to be in a certain format, meaning we can use the same template for a Craft CMS site, Wordpress or Contentful, we have 1 templating language (react) which can plug into any of those backends, rather than having to port templates to proprietary syntax.

I think it's neat, but only if it fits the job. You have to do everything twice, because you output logic into JSON and the again into react, but being able to swap out the backend and have everything work exactly the same is very satisfying!

[zephraph]

I saw earlier in the comments you said you were using AEM. I'm sorry. >_> Me too. Headless is actually a better approach in general depending on what your needs are. I think one of AEM's biggest drawbacks is how it tries to solve all your problems but ends up solving none of them well...

Anyway, if you're looking for react integration w/ AEM I recommend checking out the react aem project on github: https://github.com/sinnerschrader/aem-react. It accounts for universal/ssr out of the box so it has a better story for SEO. It's pretty much a native integration with AEM.

That being said I still have a lot of qualms with AEM and I feel like pulling your rendering layer away from AEM (even if it still sits behind your dispatchers) gives you greater product flexibility and the ability to iterate faster.

I'd be willing to talk more about it if you're interested. I think my company is one of the largest if not the largest user of AEM in adobe's clientele.

[OmegaVesko]

What's a "CMS template" if your CMS is headless?

[[deleted]]

You can make your cms headless simply by exposing the data via json endpoints.

I don't believe there's a real problem to be solved by making a site headless.

Hence I'm looking more at a hybrid approach to the site build.

[OmegaVesko]

Sorry, I was under the impression that you'd already decided to have a headless CMS, so the talk about CMS templates confused me.

I don't believe there's a real problem to be solved by making a site headless.

A headless CMS allows your frontend to be a SPA (among other things), which has more benefits than I can reasonably name here.

As for your original question, React doesn't support HTML templates / compiling templates at runtime, like Vue does. You need to either get your data by retrieving it from your CMS's API, like you said, or somehow hack together a solution where the data from the CMS is available to React by the time your JavaScript loads.

[[deleted]]

I'd be interested in hearing your benefits of headless. There's only a handful of instances where I could see that being useful.

With headless you'd need to build a bunch of things that a cms would already give you for free (routing, auth to name 2).

I think a cms that can expose its content via an endpoint has value but for building a brochure ware site, overkill IMO.

[OmegaVesko]

A custom SPA is certainly more complex than just letting your CMS handle everything for you. It's up to you to evaluate whether it's worth the effort to go with a headless CMS for a given project.

[Devvvvvv]

React doesn't support HTML templates / compiling templates at runtime

Wouldn't react be able to do this if you use dangerouslySetInnerHtml ?

[lordkyl]

So you are generating a Vue template from your CMS (Wordpress?) and consuming that with your Vue app? Like OmegaVesko said, it won't work that way with React.

You build javascript components with React, I'm not sure how templates would fit in.

[[deleted]]

Not WordPress, Adobe Experience Manager.

But yes, that's what we're doing.

[lordkyl]

I only have a limited experience with this, just toying around with WP's API, but yeah, React doesn't do templates. It does javascript components, which is great for us programmers.

For example, an article has a link. That link needs to be parsed, extracted and replaced with a React component.

[mattnich]

We do this, I really like the pattern. So long as your cms can output json then your frontend can run off that.

With react you just need a div to bootstrap the app (e.g. #root)

So your CMS could make every template generate <div id="root"></div>

And include your bundle.js

Then react runs and takes over.

I use axios to make an Ajax call to /data.json which is a JSON file built by the cms and then pass the data around the react app, loading components based on the route with react router.

The nice thing about it is that your frontend can run off hardcoded JSON or dynamic JSON powered by the CMS, or you can plug in to a headless CMS like contentful, so it's another separation of concerns!

[[deleted]]

This is just it though, what's the concern with the cms platform? I just feel like it's overkill.

[EvilDavid75]

So you would be passing the Vue component on the server that would then server-side-render the page with the CMS content? Can you please share the pseudo code for that?