Live data was stored somewhere, so it could be consumed by the Element API

[angrybrad]

Created by: Jochen F. (jochen.francois@gmail.com) on 2016/10/26 17:22:02 +0000
Votes at time of UserVoice import: 1

---

One of the best features of Craft CMS is the fact that it allows for "live preview". Unfortunately, this is only possible if the front-end is build using the Twig template engine. If you are creating a SPA using their Element API, there is no way to access this data to simulate the same experience.

[oddnavy]

We're keen to use Craft CMS as a headless CMS but "live preview" would be sorely missed. Clients absolutely love it.

Is this on the roadmap?

Related issue on CraftQL: markhuot/craftql#31

[brandonkelly]

We’re tossing around some ideas for it. There aren’t any really obvious answers though, since Craft isn’t the one serving the rendered content when it is used as a headless CMS.

One option could be that we implement custom Live Preview targets (#1489) where you supply a URL that Live Preview should POST to with all the field data.

[tonymilne]

@oddnavy and i are working through this together, and to try and help stimulate further discussion, i'll use some examples of what we're doing and what we've tried.

Take a section that includes the following fields:

{
  Title (default): Plain Text
  Image: Asset
}

Under normal headless usage, our custom web app receives a request and makes a query to Craft (using the CraftQL plugin) for an Entry by uri.
This will be successful, in which we can currently render the page or it will be a 404. We have this working already and it's great!

When we are logged in as a content editor and press the Live Preview button, we end up generating a POST request from Craft to our custom web app with the following data:
POST /about-us?token=abcde12345

{ 
  title: About Us
  fields[image]: 
  fields[image][0]: 10
  slug: about-us
  parentId: 
  postDate[date]: 26/2/2019
  postDate[timezone]: Australia/Melbourne
  postDate[time]: 16:30
  expiryDate[date]: 
  expiryDate[timezone]: Australia/Melbourne
  expiryDate[time]: 
  enabled: 1
  sectionId: 1
  entryId: 2
  siteId: 1
  versionId: 
}

Without modifying our custom web app, it will continue to query Craft for an Entry by uri and show the most recently published version. We want to address this...

One option we have is to modify the custom web app to just use the POSTed data. This works ok for plain text fields, but would require us to write logic to resolve the related data (e.g. fields[image][0]: 10). Our CraftQL queries use Transforms, so we'd be doing stuff like that too.
This feels like it is outside the responsibility of the custom web app and instead lies within the scope of Craft (or the CraftQL plugin). It also means anyone else wanting headless+live preview would have to create all of that themselves too!

Instead what i think needs to happen is to pass the live preview token (["live-preview/preview",{"previewAction":"entries/preview-entry","userId":"1"}]) into Craft (or the CraftQL plugin) so that it can conditionally return the most recently published version OR the live preview version respectively according to whether a live preview token was passed with the request.

I suspect this is currently difficult if the live preview data isn't persisted; could the live preview data be persisted in a similar way to drafts or as a "special" entry version? If that were the case, i can imagine this being really easy for the CraftQL plugin to implement.

Appreciate your internal discussion and feedback already, and i'd happily get involved in any way i can. Thank you!

EDIT: Just to be clear -- it's not so much the Live Preview target, since we can already get the POST data inside of our custom web app... it's the resolution of all of the related data and Craft functionality that is tripping us up.

[brandonkelly]

Yeah, so that’s another route we’re also considering, but Live Preview is available to more than just Entries, so it’s something we’ll need to solve for all element types. Plan for this would be:

1. Get versions & drafts working for all element types
2. Auto-save all in-progress work as drafts
3. Live Preview pages should be handed a revision UID that could be applied to all element queries / GraphQL queries to load the draft/version content.

We’re planning on making some major content modeling & storage changes in Craft 4, so that will be a good opportunity to address these. (Not sure on the ETA for that though.)

[narration-sd]

Guys, I have a well exercised back end which takes care of the data problem, and two front end architectures. The second one, done in past two weeks for Gatsby, is where I want the delivered plugin to go for all platforms, for good reasons. I'm moving faster than I should and nearly can...but the principle should go beyond entries as Brandon wants to.

I'll try to get a little movie together for comment, maybe tomorrow late or if not Friday, showing a Vue SPA app and a Gatsby-React site as applications, editing in the expected Craft way, and on the web. I know you want to rush, but I suspect patience would be a virtue.

And now it's very late here.

[narration-sd]

I wanted to provide you the film as promised -- if a little after eleven.

https://goo.gl/ZWhxC4   

-- that's a dropbox mp4 that'll play on your browser, best if you click lower right to make it full screen
-- yes, it could use explanation. I'll write a bit tomorrow. I think you'll get the idea, though.
-- what you'll see is first a Vue demo app, and then after it, a Gatsby one
-- the apps are first live on a DO droplet, and then being edited there with Live Preview, via Live Vue
-- CraftQL is being used for all editing and site views; Element API is possible also, as in the first app

Of course I'll do a better film, with narration (!) and so forth. This is what I could come up with on short notice, while not totally interrupting the process that's getting Live Vue to the plugin store.

p.s. I did consider some nice background music, to take the curse off this if I could not do more tonight, but copyrights; and anyway quiet seems welcome…

[narration-sd]

...and, well, I had a look through the uploaded video just to be sure, and noticed then that I did all the Gatsby parts with that site in devMode on, so that CraftQL and hence app screen updates were really slowed by all its extra checks.

I had anyway wanted to compllment @markhuot again on how much he's brought the performance up recently, and that saved the occasion, as I’m not going to do this over again tonight.

How I handle the various latencies that will crop up in wider use is an interesting topic, anyway, for future. Natalia Lafourcade has my ear for this evening….

And this may prove a useful beginning: https://narrationsd.com/docs/live-vue/

[oddnavy]

Thanks, @brandonkelly! Having Live Preview would make Craft an even better candidate when choosing a headless CMS. Hopefully it makes it into the Craft 4 release.

@narration-sd is your plugin available online for testing?

[narration-sd]

@oddnavy, @tonymilne

David, I've taken a deeper look at Inlight, and it certainly looks like Tony has a strong team, not to say a great agency title. I note that React has a big presence, and this guides some thinking. I'm open to learning more about the project frame you guys would like to work at present, as this will influence timing -- depends on what you need.

I've dug up an email for you, and will send a note.

As far as the back-end plugin which does all the work, this is as proving as robust as ever. On the weekend an idea for the browser frameworks side drew me into coming up with something that will be a great improvement all around, particularly for the most challenging cases, and also simplifying. It's halfway to being implemented to prove this out.

With this result, status for a beta is near, and as it's sensible, that's where Inlight could have a look.

Clive

[brandonkelly]

This has been added for the next 3.2 Alpha release! Preview requests will have a token query string parameter, and as long as you pass that along to your Element API (or other API) request, the draft content will be returned instead of the main entry content.

[narration-sd]

Hey, Brandon @brandonkelly, congrats on getting this to go!

I was watching your notes flash by last night while doing infrastructure on getting the completed Live Vue plugin's support ready for the Store, and with a little back of the envelope this morning, looks like it's going to mesh right in, with a very comfortable transition.

All the things Live Vue does to enable essentially unmodified SPAs to show previews just by themselves (!) remain essential, and with the addition of Hal that came out of the beta, should even be fun to use. In summary, as smooth as with Twig.

Your draft entries will mean I don't have to maintain and watch robustness/resilience on the HiddenRecord object manager that does fine at present, and will become an interface. Great, actually!

Really happy to hear what you've done handles recent questions about Matrix and probably related aggregating types also - Live Vue's architecture just follows what you put in previews already, so the more reliable/resilient, of course the better, and for Craft.

So, there are lots of connections, aren't there, given the FRs you're closing etc.. A couple of thoughts around the edges:

• I'm first underlining Carl's compliment -- Matrix blocks don't appear correctly for Live Preview when using additional query parameters #2801 (comment),

• a request I'm going to think further about once this thing is well in the field -- have had some solutions imagined about deeper operations in advanced SPAS, and GraphQL should make this especially seamless - Multiple Live Preview Targets #1489 (comment)

• Live Vue's initially for Gatsby, with Gridsome looking close, and their underlying general platforms Vue and React appear to be a matter of documentation. I hadn't considered much about Angular, but if there's demand, the architecture should do that also -- Live Preview with Angular 1.6 #2120 (comment)

Enough am sure, but always impressed with the energy you and the team bring to getting closures, each time very good and thoughtful ones, on all that matters in Craft, Brandon.

Clive

[brandonkelly]

Glad to hear that, @narration-sd!

[narration-sd]

Just to let you know, this all worked, after two sessions on a Saturday.

It's not in the version that's about to release, but is prototyped on a branch and doing previews nicely, with Vue this time, so now suiting 3.2 and its changes is validated. One or two highly interesting things to figure out along the way...but result is simple, which is great.

A p.s. @brandonkelly, that following your ongoing support comments can be very useful...!