Web Components for CMS (Polymer Summit 2017)

Key Takeaways

[Music] hi everyone - my name's bead I'm a developer from Melbourne in Australia and I work on a content management platform called simpler so I'm here to talk to you a bit about web components for content management systems so I've been working with CMS's for a while and honestly I've been a bit frustrated with them essentially I've been frustrated both from a developer's point of view and also as a content editor I've been frustrated a couple of years ago though I started using web components and I realized these could potentially really change the way we look at content management and they could help resolve some of these frustrations so that's what I'm going to talk about today I'm going to talk a bit about content management systems where there have been in the past and where they are now and help web components could potentially change them I'm also then going to go over some of the patterns you might use to build out your own custom element for content management so let's first look at a monolithic CMS so a monolithic CMS is essentially your your traditional CMS such as a WordPress or Drupal it essentially gives you all the functionality that you need in one single app so on the one hand this is great it means it's really easy to set up and get going with but like any monolithic system it means it's quite rigid so from a developer's perspective it can be quite difficult for example to change the way you're displaying that content for example if you want to use a different framework or a different templating system it's going to be really hard to wangle that in with the monolithic system also for a content editor you're going to have a bit of frustration there so most of these systems you're going to have some kind of a dashboard where you log in and you edit that content in a form the problem with this is that that content there is in a completely different context to what your user is going to see it's a very different environment so for your content editor they're going to get a real disconnect between what they're seeing and what the user is going to be seeing over the last few years though there's been a huge huge rising popularity for something called the headless CMS so the headless CMS essentially takes this monolithic system and gets rid of the view layout instead it replaces it with generally a really consumable json api or similar essentially for developers this is this is fantastic because at this point they don't actually have to deal with the CMS instead what they're dealing with is just an API so they can really use whatever framework or library or back-end that they want to talk to that content generally though these systems are going to end up with a dashboard just like the monolithic systems where you have to go into some form and edit that content in a different environment to your users viewing the content so this is where components come in what if we had a componentized model for content management the idea here is that you essentially build upon a headless system with that API to a consume content except you take that view layer on the monolithic system and you break it down into really small chunks of data such as image text or something a bit higher level like a blog post so this is already being done on the dashboard of these other systems if you go in you'll edit a content type so in a kind of componentized manner but the idea here is that that view layer is insert is embedded into the component itself when it's delivered to the user in the browser on top of this we're also adding in a editing layer that's embedded inside the component itself so for our content editors they're actually able to go in and edit that content in the exact same place and same environment that users are going to be viewing that content also because this is a small modular and componentized system we're trying to retain a level of flexibility for the developer so that they can still have control over this content and how it's displayed so why am I talking about this now in the context of web components so first of all custom elements is the first time that we truly have interoperability before any componentized model was going to be restricted to the framework it was working in this way we can build components that can actually be distributed to any HTML environment modern this we also have encapsulation through shadow Dom so that we can make sure that editing you why isn't having any side effects to the rest of the dom so what would this look like so here i've got a dynamic image custom element with a path property that maps to some URL somewhere essentially it's just pointing to some data i want at some point for it to fetch from an api and i want to render out that content so in this scenario that means an image tag later on i then want it to save back to that same endpoint so we'll do a put request there so this is for a developer this is generally what we'll see what about that editing experience so for example here we want the edit to be able to come in interact with that image in an isolated environment maybe upload a new one manipulated manipulated in some way and then be able to escape all in the context of that one image and see what the user is going to see so how would we build that so i'm going to go through a basic primitive i'm going to go through that dynamic image and i'm going to focus on the fundamentals of the content part of that component so i won't touch on the server and i won't touch on the internals of that editing UI so this means i'm going to look at how do we store that content how do we render it onto the page for the user how do we toggle that editing UI to manipulate it and obviously how do we get and set that content over a network so first of all we need to create a basic dynamic image gentleman and that's inheriting from the base polymer element and straightaway as early as possible we want to set up an image on our instance that's going to act as a rendering point for all that data we're going to have next up we want to append this into the light dom in the connected callback so we want to do this in the connected callback because only once the element is inserted into the dom do we know that the user actually wants to start consuming this content we also need to make sure that we're doing this into the light dom not the shadow dom at this point and that's because content should fundamentally still be accessible to the user for example if if they want to use any third-party stylesheet or any third-party library that expects an image tag to be on the screen you need to be able to make sure that's accessible this also opens up the door for really easy server-side rendering so as long as your content is in the light Dom anything that can spit out a HTML string can server-side render so let's look at some properties here essentially what we want is we want some properties that are going to be able to hold all of the content to display that image so for us that's pretty simple that's just a source and an old property you could add some more meta information if you need but this is fundamentally what we need we also have a render function so this is an observer for those two properties so this is going to get called every time and just pass those props down to our image this might be more complex in other scenarios so if you're building an article element that's based on markdown you might store the content and markdown so your render function is actually going to have to take that markdown and convert it into HTML so at this point we're storing some content we're rendering it out to the Dom which is great but it's pretty basic it's essentially just a wrapper frame image it's not doing much so let's look at adding in some editing controls so on the right I've got my template which is how I want my shadow Dom to look for this dynamic image element and essentially we're encapsulating all the editing functionality into it now you'll note my editor controls is surrounding the content but really that's just depending on the structure of your editing UI it is important though it is beneficial for all of your editing functionality to be packaged into one element just because this means that it's a clean separation of concerns and also is going to give you a performance benefit which I'll talk about later so first off we need a way to make sure that our we can toggle those controls open and closed so we've just added an editing property to the host and an opening open property on our editor controls and all this is doing is just making sure our host can control when they're open and closed we also obviously need to pass down that prop those properties and that data to our editor controls and at this point we don't really care what editor controls is doing under the hood it might prompt the user for a file it might bring up a canvas to manipulate it but essentially we're just giving it at the data and at some point in the future we know we're going to want that change data lastly I want to look at a load controls method so most of the time with a dynamic image most people that use it mostly we'll come to your site with a dynamic image on it are just going to be viewing the content they don't actually want to edit it so we don't want to burden them with the functionality that comes with the editor controls so what we want to do is we want to have this observer function that when editing goes to true we can then import a HTML file that has the data has the definition of editor controls inside of it and only at that point once we know that the user definitely wants to edit we can load in and pass and boot up the JavaScript data for editing you can actually do more than this you'll notice this entire shadow Dom is only for editing so you could actually defer all of your work for for for dealing with a shadow Dom until the user is actually editing content so now we have a dynamic image it can display some content for the user and you can add an editing proper which will open up some controls that you can start manipulating it this is pretty simple and it's a nice base to work on we have an interactive and dynamic image element but it's not there yet we really need to have some kind of networking to be able to load and persist that data so first up you need some kind of property which is going to let you uniquely identify the data it's talking to so I've chosen a path here to map to some kind of URL but you could choose a unique ID whatever essentially is going to pass you back to a unique URL we're also going to need a deserialized function essentially just a way to take whatever the server is giving to us and hydrate our own properties from that information again this API is pretty it's pretty simple it's giving us nice those source and all property straight up but in other scenarios you might not have control over that API so your deserialized function might have to do a little bit more work conversely we're also going to need a serialize function which is just going to do that same process in Reverse we just want to take the content stored for us that's our properties package it into an object literal that can be sent over the wire later on and obviously we need some methods to actually perform these requests so our load method is fetching a URL based on that path property we're taking that jason passing it and giving it over to our deserialized function the same again pretty similar just do in Reverse so we're getting that serialized function we're calling it trying to get into a string and sending it over to our API via put method so this save function you're really going to want to wire that up to some external UI for example a Save button that you might have on a page or perhaps an internal event such as those editor controls maybe when they close you want to automatically save lastly we want to make sure that we're loading in that content of the appropriate time so I'm doing this in the connected callback because basically you want to make sure that you're not making a network request too early but you want to make sure they're getting it at the right time so once the element is in the Dom we're making that network request but you could be a bit smarter than this for example you could use something like an intersection observer so that you could load in that content only once the element has been scrolled onto the page itself so now we have you know a pretty simple image but it can display content it can provide an editing UI so that you can edit it in place and get feedback on on that ending and it can also dynamically fetch that content from a network endpoint and persist it back to that same endpoint but this is just one component ultimately to get to a CMS you need more than this you need a whole library of components and that's what we've been doing with simpler so we've been developing out a bunch of primitive elements such as video or image and text and bringing them all together using other mechanisms such as authentication systems and global management systems that are able to synchronize save events amongst all the elements and and make sure they're all editable at the same time but more than just a single CMS wouldn't be great if we had an ecosystem of these dynamic elements where people could mix and match and use the ones they need based on their website or app and what if we could have a plug-in system for those api's so that you could choose the content source that you're using for a specific element you could have multiple content sources on the one page ultimately I think using all of these together and utilizing web components and the features that it gives us I think we could really see a different approach and a better way to manipulate and use content on the web so thanks very much I hope this has been interesting please if you're interested at all come and chat to me afterwards Thanks [Applause] [Music] you [Music]