Wagtail headless and NextJS frontend - Lucas Moeskops

Speaker 1: I want to talk about using NextS uh as a format for websites built in Lactive. Next CS is a framework Built on React. Uh but first with Ludwig. I'm uh Lukas, a software developer from uh Fabric, uh designer office in Amsterdam, and we mainly build websites in the uh museum sector and sector. and we uh focus heavily on front end design. Um so a lot of our developers are front end developers. Um I really like like uh the idea of has a CMS

Speaker 1: uh for um building websites um because uh for years we struggled uh a lot with uh the possibilities of the Django tempted language and um for our float-end business to learn those and at the same time there's a lot of improvements in the uh JavaScript center where frameworks are more common and uh people uh have more and more experience with frameworks And less experience with playing HTML and JavaScript. So I think it's nice if the atlas option for Wagtail would be developed very well and easy to use with frameworks. great for um separating the back

Speaker 1: end to front end logic uh so we could more easily have uh well um multiple apps that use the same API and same CMS and uh the back end uh and um you can also more easily decouple stuff. You could have a new design for it and still keep the same API. I think this is at the moment a major struggle often. Um so yeah, I think headless is Nice. I also like NextJS. It's a relatively new framework built on React and it solves a lot of the problems why we didn't want to use frameworks mainly support for search engines. optimization uh and

Speaker 1: um uh well uh images and a lot of stuff is just out of the box in XCS and they have a nice access community uh so I hope that stays away. I think uh it's nice to try to build websites with that. Uh also it's built on React. Um of course you everyone has their favourite framework, uh but I think React uh sta is already developed for many years and uh there's a lot of stuff available so. it's way easier to find solutions for common problems in React often for developers than it is in uh well nearly JavaScript it's pretty hard often and uh well in more uh obscure frameworks like Svelte, it seems really nice. Uh I'm still worried that it's too new

Speaker 1: for not sure how long it will stay. So I think this is a a nice one. Um yeah so how can we combine WebTel and SES in a nice way. I've been uh looking how to uh work on that and uh how we can uh easily integrate it and make it uh logic and easy for everyone to build website with it. Um Yeah there is already uh existing work on this. Uh there's a repository called VegTil Pivot, which is by a Swedish company, I think it's called Freud. Um they did very nice work on building a cookie cutter project with uh WegTil and Nex. Um I like a lot what they've been doing and they have been solving a lot of common problems

Speaker 1: like uh review modes and uh and proper protective paces and stuff like that. Uh but they also are very opinionated. in my opinion. Um you have to use the the computer cutter is very uh custom, it doesn't use a vector API mostly, it's just uses Rust Framework API and uh it has integration with a lot of stuff and storybook which I really like. But for me it feels also that you don't really have your own choices anymore because you have to do it that way. So I was looking a bit further like how can we make it more general? Uh then I noticed hope. Uh but they will also have It was uh operating with Next. js. Uh WebTel currently has a fairly called RVS yet

Speaker 1: where they are doing also some research on Next. js, which is really nice and they keep track of uh what how far they are. Um so I was surprised that uh WebTil themselves are also interested in Next ES and Heavy. So then I arrived at the WebTil space and wanted to improve on the Next ES um stuff and I noticed that a lot of people from WebTil and other classes are also interested in XS because this is the stuff great. Um so what I wanted to do to uh show better how to integrate uh WebTil and XGS is uh uh use the next uh the webtail bakery jet demo uh to turn it into uh projects product with uh

Speaker 1: webtail and next together so that bakery demo uh the bakery demo is uh a webtail demo site for uh new development. To um learn to work with Wagtil uh and see what the possibilities of the CMS are. So it's a repository you can check out and uh and then you can play around with WebTil. Um I think it's nice to turn it into uh Correct, where it uses NextGS as a front end and uh you can learn how to uh how you can solve uh the problems uh with Next Yes and you can also talk about it and see how it can be done even better. And And uh maybe you can make uh a Wactail helper package to uh better integrate next year later. So I want to talk about uh

Speaker 1: how I sold some stuff for the Wactail Baker sites and uh some common topics that are occurring when you have Uh when you try to make ha has uh CMS uh front end uh like routing of pages and different templates and how can we make stream fields render correctly and risk text is pretty hard. Images are interesting. and uh well then you have the more advanced adding features. Uh and then you have caching and forms. Casting mainly because the front framework also offers uh and actually has uh the option to do service address rendering. That's the incremental static generation that's I really like and then the cut the basis generated on the website, the static

Speaker 1: sorry on the server, the static generation. And for next request you only have to download static cases. you know uh and it will be really fast. Uh then there's incremental study generation that means that the faces are not necessarily generated on server, but they are generated on server when the user first requests them. So I think This is very useful for Vectail because people will make new uh new pages all the time and uh you don't necessarily want to immediately generate everything all the time. So this is a feature I really like. Uh server-side rendering on the other hand uh just means that every request by any any client in the browser it will uh do a request to NextCS and to BackTill. Um so you can more customly build uh the base

Speaker 1: so it has less issues with caching, static generation has issues with caching because uh well when you change something uh you cannot use the static generated HTML again. So then we also need solutions for that. Alright so the typical NetVS is a is that NetVS is a server uh serve the on the server and on the client. And the client just requests a page from NatJS and NGS says like, oh it's a Dincast so I can just send to or NGS Tinks. I don't have DNCS and I need to build it and then I need Web to help me build page. And then you can serve it to the client and the client can from then on also uh call the Wacto API to further build the page

Speaker 1: and get more out of it. Yes, so I want to show some coding. Alright, so here we have the Webflow bakery demo CMS with the Webflow 3. 0 million bars. Uh yeah, so over this webflow. And here we have the bakery demo. This is already running on Next Yes. I don't have every component copied. I'm just going gradually over it. I want to talk about is routing. So uh when you go somewhere uh you would like uh this this is the routing uh URLs, so you want them

Speaker 1: to to be able to manage them. And Next H provides routing options. They have a directory called pages and you can build your own routes here. Here uh indexes is a phone name, but any name you put here as a file is like a URL segment that you can use uh as a page. Then it also has variable pages. So in this case uh I just grab the whole path as an array as an option from S and uh this will be a catch-all that will just um find any page that uh a user requests. Uh and what I'm actually doing then is I call the webfile API uh endpoints and it will give me uh I can send an HTML URL to it and then it will give me the

Speaker 1: a redirect URL to the page That is uh connected to that uh URL. And then I can uh get the page data from that. Actually this function is doing that. Uh so that's that allows me to uh get the vector API. For any page that I uh that is requested by the user. And I think that's the best way to solve uh um routing for now because from back there you you can do any routing you like, you can create any page you like. And actually So just ask Wegtail which space uh is actually uh needed and then uh you can render it. Um yeah so what happens when a page arrives? Uh we basically get the page

Speaker 1: data from Wegtail. Currently I say revalidate after 12 hours well based on uh how much you like the guessing I think it's mostly should be less. Um and then I just render base components uh which will uh be like the base HTML from vector templates like the the basic uh page. So next you have an option to create a head uh element which will fill the head for a certain URL. So it's very eas useful for uh social OG tags and uh search engine optimization because uh any page can have a different URL, a different uh tags. And you can also uh add components to it uh in different uh in different components you can add

Speaker 1: stuff to it by just using this hat rubber and next yes we'll gather everything together and put it in the head. Yeah so currently I render here the basic structure of the vector base with this a menu bar Red crumbs obviously and uh a template. So uh um yeah, of course you can have different templates because uh in vector you have the base models, so e every base model can have a different template. So we can solve that by mapping the templates from WebTL to templates from React. So here I say if I have home gates, I want to render

Speaker 1: And if I have a breath page I want to run the bread text templates and etc. Um the nice part is also that this dynamic allows uh the code only to be loaded when it's necessary, so your adjust with code that needs to be downloaded is smaller. Yeah, so then we would load, for example, the homepage in this case. And then it will render basically I copied the Wagtail homepage templates and rewrote it to React. It's it's kind of the same as HTML for the most part. And I think the react looks pretty clean and nice. That's what I like about it. Uh yeah, so what I noticed, what I didn't know when working with a web API, it's actually already quite uh powerful. Uh you can

Speaker 1: query the fields you like at any moment, uh and you can query lists of stuff and you can um a lot of it is already inside, so actually I had less problems making uh Web Nexus components than I uh assumed. But I do think it would be nice uh if we have problems that we can see if the vector FI needs to be improved for some points. Uh yeah, so that's nice to research. So for example for in this space, the bread space. Uh I 'm sorry. So here we have a selection of reds and we have destination. So in the React component I can actually just call the WebTel API and say, hey I want uh six threads and in alphabetical order or whatever order I want.

Speaker 1: Uh and then when I go to the next page uh I can query different selection neck uh of uh things. So it's uh well it's dynamic loading uh network. pretty fast and well I think. So how can we render stream fields? Uh in the admin multiple stream fields can be defined and uh each has their own rendering. Um but the nice thing is that WebTel API already uh supports uh nest nested fuel stream fields to API. Uh I can also show by the JSON nested score this page. This isn't this is an example of a complex query you can do you can just uh basically uh puts a query what stuff you want and you can

Speaker 1: specify what skills you want and then you get like really pistoning. Uh oh um So for example for numbers you guys. Uh yeah, so basically components and then the extreme fields, for example, I think it's called body. Yeah, so then we get a paragraph work uh as simple as a type telling ID. Uh and then we next years we can also render these by uh well for example. I can make a mapping from

Speaker 1: blocks just like the templates to uh templates that will be rendered for the block and then I can actually loop over the strengths and just render these blocks. For that I also made the component vectors. So then I get this uh risk text. Uh yeah, so risk text is also pretty hard because uh Uh BackTelf by default it will uh create references in the rich text uh output. Uh so I think that's something that could be improved in the API. And I think someone was working also on it in the in this in this uh sprint, so that's super nice. Uh that uh the page URLs are actually uh URLs and not uh links to pages because that's hard to uh

Speaker 1: to uh find the correct page for in WebT or in uh X. So I'm basically using to convert the the RIST text is uh a utility uh where I found this rewrites HML to react and I can uh turn elements into uh next JS elements. For example the anchor element. MaxDS likes the hasn't link component uh which uh does which recognize that the link is uh an internal link on the website and then it can already prefetch uh links on the page that you are on. So loading will be a lot faster. So it's really nice to make use of that to uh go around the website because it

Speaker 1: will feel very fast and not flashy. So uh I process each graph text element uh with these uh with this function to turn it into uh react actually and then I can manipulate it. So it's pretty useful I think. Uh yeah then Images uh are always hard to responsive images, uh but NextGS has a nice image component that uh actually maps pretty well to the Vector API output. So uh in the end for simple images I only need um uh I can almost directly map them to

Speaker 1: uh to an XMS. Here I'm actually doing an experience experiment with uh Optimizing the width and height, but basically I can just render the next image, uh convert the source depending on how your server settings are to the to the correct SVC RL, and I can just map the width and hydro the image to it uh and it will work

Speaker 2: absolutely

Speaker 1: pretty well. Uh next year supports multiple layouts. So here I run an image and I say the fill layout and then it will fill a goal container just like an original and other Otherwise you can also use the regular layouts and you have some similar some different layouts based on what you exactly need for images because we have different use cases. So what I also do for running images uh on the back end I um I use API fields from Webfield. So WebFill API fields that uh and then you can put database fields and model fields from your API you can expose them

Speaker 1: and often you will need some uh uh some customization on it so then you can use seri serializes their uh Rust framework concepts uh that allows You to customize the output of certain fields. So, for example, for images, I use a rendition field because I like to keep the Wactio focus points functionality and that's currently in Wactio. So I first First make a basic uh cutout from the image and then I let uh Next Yes uh handle the image. Uh an X built-in image uh handler is already pretty good. It uses the sharp JavaScript library. Um and It's pretty good at resizing and rescaling so

Speaker 1: this will work pretty fast in working in uh in my experience. Uh I'm happy with that. Uh also More advanced options if you really want faster images then there's support for external loaders. Uh so that these are external services that can prop and use your images uh and serve your images really fast. I think they are very interesting to explore, but uh then you also have to find out how to combine it with a work tail focus points functionality because you would like to keep the CMS behavior from what you expect to get and what the MS will give you. Uh yeah, then uh caching is always an issue, so the server-size rendering is by far the easiest option.

Speaker 1: Uh for simple sites I think it's nice um to use the standard generation for really fast sites uh and Next year I wrote a simple backhand for the rectal frontend cast. That will uh since recently Next CS is support. With its own API which allows you to uh invalidate uh static generated pages. So uh with a vector funded cache I can see if someone saves the vector page and then the vector funded cache will call uh the next API extra. and uh uh request the base to be first and then uh I can use uh

Speaker 1: well I think have guest static pages and on save I can have them refreshed, which is really nice. Well for menu changes it's harder of course, so therefore I think it's nice to at least refresh your whole next pages every 10 minutes or whatever. Um oh that 's my presentation. Uh just

Speaker 1: um oh yeah, for view modes I made Like a hacky version of V mode that will work for uh uh draft pages and also it's protected with a password. Um but I notice now that Wactor has their own headless review page, which I think is way better and uh supports everything, so I still need to see how I can integrate it because that's great. Then the admin user bar is also a very nice feature for users. I think it shows the uh people at Torchbox called the edit It's the word in the bottom right that allows you to uh edit the current page. Uh I think it's really useful for admin users. Um but it can of course not be cast on a static page. So on every page I do an extra call to the back

Speaker 1: end to see if the user is logged in. And if so, I just rendered a static HTML from the template tag and put it here and it works, so it's nice. Um that's for that. Um uh well forms are actually pretty hard. I thought I'll f solve forums also, but um they still need some more support from the Vectual FI possibly, but I also have to research it and I think also someone from Overcast was doing some work on it. This is nice. So I hope actually to make progress on this soon and be able to integrate forms uh also easily. But it's not uh very easy at the moment. Okay, well, so to summarize, uh

Speaker 1: I think the Waco API is already pretty good and it needs some minor tweaks to uh for a little bit better support, like uh maybe basically basic uh rendition field support for stream field blocks and uh risk text conversion for stream field. I think it would be nice if you could have at some point like a vector package for Next VS or a vector package. So that uh it will be even more even easier to uh uh use next and have the the great uh uh and have an easy integration. Um yeah so each topic has actually multiple ways of handling them instead I really like our next CS that it's so open that you can uh still investigate

Speaker 1: So uh yeah, stuff I would like to do further research on now is the form support and routerable pages, but also is related to form support in a way. Uh initialization has internationalization and backfield has international nationalisation but I haven't um they work together but I haven't done it very thorough thoroughly so I might have been some problems and also someone from Blackfield space was having some problems with it. There's some stuff to fix there. Uh and then as fun statement features, I think uh the pipett Wagtail packets solve some of those, so they are very interesting to look at. Uh and also Wagtail solved some of those with uh has a P package so well. Uh that's a ri there's progress being made. Uh that's nice.

Speaker 1: And then there's guessing. I'm not sure. Uh I think uh we'll see later about how that's I think it's basically very custom what you need for guessing. So that's what I want to share. So thanks. Any questions?

Speaker 3: Any questions? Anybody?

Speaker 1: Yes, yes. Uh uh Vector API is basically a REST framework uh so it's built on REST framework and it basically uses all features from REST framework. Um But

Speaker 4: but the data format is not the error uh standard. Uh but JSON API defines relationships uh that kind of stuff. Um of course you can you can add an URL and so that it you can use another framework than Next PS to to talk to the uh to the API without needing to to write a new matteration data.

Speaker 1: Yeah compare items, no for inside actually , look nice