About this talk
In this talk, Felix, a staff engineer at Acquia, discusses the backend workings of the Canvas framework integrated with Drupal. He explains the concept of components as config entities managed by Canvas, emphasizing their role in rendering layouts with specific inputs. The speaker describes how components are created, validated, and organized into a tree structure for efficient rendering within the Drupal environment. He covers topics including component sources, explicit and implicit inputs, and the structure of data storage for component trees. Additionally, Felix shares insights into shape matching for component props and the handling of prop sources, illustrating the flexible capabilities of Canvas for managing complex data types.
Full transcript
Okay, well, hello everyone. Thanks for coming. There's way more people than I anticipated. I hope everyone had a nice filling lunch and it that's a perfect session to nap at. Technical Drupal stuff. Uh my name is Felix. I am staff engineer at Acquia and for the past 2 years I've been working either on Canvas or with things uh directly integrating with Canvas. I will start with an
apology because uh now is the time to leave. If that doesn't go well with people, but uh the description of the session was written back in October of last year during during Drupal Con Vienna. And some of the things I promised in the session uh we didn't get to work on them and they were they were not covered like the paragraphs uh layout builder and config management
is not going to be part of the session sadly. Um so there's still time to catch something more interesting. Uh but if you're here to learn about how Canvas works from the back end perspective, uh it's still going to be a good session. I will try to keep all the things that are vital to know about the the how Canvas works. So, also no AI will be
discussed in this uh session. I also haven't used uh any AI when making this. Uh I think captions might be using AI. So, if the slides are looking like crap, it's because I made them. So, this is what we will be covering in this session and roughly how long each individual topic should take. Uh if I don't ramble too much, there will be time for Q&A after
a short live demo. And if there won't be that many questions, surely, uh we can have more slides, I guess. extras. let's start with the components. So, there are two ways to think about the components. So, the one way that everyone describes them is like an isolated piece of markup with some functionality that can have inputs and is used for rendering. The intent of it is in
general to build layouts of pages. Uh but from the back-end perspective, the description specifically in Canvas changes a little bit. So, components are config entities uh managed by Canvas. Uh they mainly used as abstraction for other APIs that can have inputs and are renderable. So, we will go over each individual of these points in the detail now. So, the first one, the fun one, abstraction. So, what
do you mean by this? The config entities, component config entities, they can't render themselves and they can't hallucinate a bunch of inputs for user to interact with. They have to have something powering them for that piece of functionality. There needs to be a source of the functionality and that's what why we decided to call those things component sources. At the moment, there are three component source types.
Uh SDCs or or full name would be single directory components, block plugins, and code components. And the config entity itself uh it's uh well, it's not directly extends config entity base, but through one extra level. The purpose of it itself is to store the default settings and the version of the component at particular point in time. To represent individual compo- unique and to expose components to the
Canvas UI. So, what that last one means is that for every component config entity in your Drupal site, if it has status set to true, it will be available in your Canvas UI as a component. So, how do you create those component config entities? Uh you don't. Uh Canvas automatically generates config entities. This happens on the easiest way to say it is on a cache rebuild, but
it happens on many different in many different situations intentionally up requiring not requiring users to interact with the creation of So, for each individual component source in your site, you get a single config entity. So, Canvas automatically gen- creates component entity, validates whether that component source is valid and compatible to be used with And on any future updates or deletions of those sources, component config entities are
also handled accordingly by Canvas automatically. And if during creation or update, Canvas encounters a validation error with the component, validation errors are stored together name, so you could look up what the error was and how to fix the problem. Uh we'll cover this a little bit more in my demo. So, also, sorry, forgot to mention all the slides will be available after the presentation, so don't worry
too much about taking notes or pictures. I'm going to have a lot of slides we're going to go fast through them. um let's skip one. No, it is not. Cool. Uh one component per unique source definition. So, very simple idea. Uh so, if we will use SDC as example, for each individual SDC in comp- uh Drupal core has component plugin manager and it discovers every individual definition
and registers a plugin to represent it. Canvas in turn uses the list of those unique plugin definitions to create unique config entities. So, if you have one SDC that renders image, there's going to be one component config entity in Canvas to represent it. If you have three components SDC components, there's going to be three component entities. Components can have explicit or implicit inputs. That's terminology used in
Canvas. So, what does this mean? So, explicit inputs are the inputs directly provided by the user when they're instantiating a component. Say you place the component with a text box in a layout, you type some text. Um that's explicit input. Implicit inputs are the inputs that are not provided by the user. So, they are provided by other content displayed on the route. Um by request context or
maybe environment itself. It's things like URL queries and current user or time of the day. A good example of uh implicit inputs would be a breadcrumbs block row in in core. It knows what breadcrumbs to display based on the route it is currently being rendered on. So, explicit inputs are supported by all the current source types in component source types in Canvas. Implicit inputs are only supported
by blocks and they are supported in limited capacity. Specifically, contexts are not currently supported and there's an issue in with a link in the slides if you need or want to discuss context support. That's the issue to go to. Also, this morning Ted did a really great presentation on advanced site building and he had a section where he used views on Canvas pages. That was a good
demonstration of using implicit inputs in Canvas. So, it's too late to go there cuz it was about 4 hours ago, but once the recording will be out, maybe watch it if you're interested. If you not interested in visiting, but it's still a good session to watch, by the way. Just That's all I talked about. So, components can have slots. For most, that's a very common and fairly
familiar concept, but it's the idea that you can place components inside other components. Each component can have one It can have zero or more component slots. Each individual component slot has its own name to identify it. But only SDC and code components currently can have slots. So, visually, it what it allows us to do, it allows us to build component tree structures out of components. Oh, that's
crazy. the thing that I want to talk about next is once you build a tree structure placing next in few components within each other, how is that actually stored? So, this leads us on to the data model section. The moment there are three use cases for component trees in Canvas. There's the Canvas page entities, that's a content entity. There's content template, which is a But also there's
a pattern, which I keep forgetting exists, but it's also a config entity and it's probably very useful if you're not a back ender. So, we'll start with the Canvas pages database table for storage of the component trees and makes for a really easy way to display to to demo what it does. So, this is Kiki. And specifically, it's a Canvas page built with three components. So, at
the top level, we have a two-column container component. It's marked with the red borders. The colored markings on the on on the slide show display the boundaries of individual components here. So, the top level is the two column component which has column one and column two slots. Inside of those, there's the there's the text marked in blue. In this slot, that's a JavaScript component with some static
text input. And on the left in the column two, marked in green, it's the JavaScript image component that is currently has a Kiki the Cat image placed inside of it. So, the front end stores this information of this structure of this tiny tree in a similar block. There's a bit more to it, but if I hit publish in Canvas, this is roughly what hits the Canvas API
back end. Canvas then Canvas then takes this JSON, converts it into a slightly different more Drupal-friendly data structure, and uh stores it in a database table. This is for publish, not for the auto save. Auto save is slightly different thing it's own thing, but for save entity save Canvas entity, you get this table. So, my table was empty before I hit publish. This is the exact result
that just a change on the component inputs because a lot of text difficult to show. So, this table has all the regular uh config entity things. We have bundle, we have entity ID, revision ID, language code, the the usual suspects. But, there are also component tree-specific properties and columns. UUID, component ID, etc. We will go over what they actually do in that table and what they used
for. this is the same table. I just have removed the things we're not going to talk about because they're just Drupal And I also shortened some of the values just so it would actually fit in the slide and people could see what is happening. the three rows represent the three columns from before. The top row is the top level container column called uh con- container component called
two column. Um it's marked in red. Then we have uh JavaScript component text uh marked in blue, and JavaScript image component marked in green at the bottom. two column component is placed at the top of the component tree, so it doesn't have any parents and therefore its parent UUID and slot values are set to null. Meanwhile, the text and image they are children of the two column
component. So, in their parent UUID, they use two column UUID as a reference. And because we also need to know which slot exactly they are placed in, they also have names of their parent component slots into which they are placed. If there are more than one component placed into the same slot, uh we need to know what order they are We track that using a delta column,
which I briefly inserted between slot and UUID columns. This column is only useful in the context of deltas in slots. So, if you have multiple components in the same slot, delta is useful. For everything else, not really. So, I'm going to remove it again just to simplify the slides going forward. We also have component version column. This is deterministic hash calculated properties of a component source at
the It is somewhat related to the component inputs, but not the component input values, rather to the props and shapes of the props that were used by the component at the time this was stored. So, if you say go ahead and rename one of these props, the component version hash will change and Canvas will know that your prop definitions in your component have been updated since you
saved this. So, we can handle errors and potential problems. If you have multiple components that the instances in a component tree that use the same component config entity, because they all have the same versions of their prop definitions and and other things, the component version will also be the same, identical between them. And then finally, the inputs in this particular case. So, this is all static inputs
because it's a Canvas page. What I mean by this is that none of these values are linked per se to actual entities. Well, and I ignore the target IDs, but it's an it's an entity ID, but it still was selected manually. It's not coming from a Drupal field. These values are JSON objects, but they can be converted to essentially flat arrays named by associated flat arrays. So,
it's keyed by individual props on the component and then assigned values to that prop. So, even if we're working with a component tree, actual lookup of values and for modification or changes is actually relatively straightforward. So, what does all of this means? Because we store information about the parents and the slots. Even though this is a traditional table with columns and rows, we can take the data
and reassemble it back into the tree. And that allows us to load it back in canvas to represent what was the layers on that component tree and also render things correctly as we would expect. If we look at the content templates, most of the things function exactly the same way. Uh the main difference is that for content templates uh config entity is stored stored in YAML and
there's no rows and columns to use there. So, if I create a an article, so this is just a simple demo article title, image, a little bit of text. And then I'm going to add a component template that renders articles in few full con- content display mode. When we save this entity, Oh, one thing to mention. It's the exactly same structure as before. Uh where it's two
column components for the container at the top level. On the left we have text, on the right we have image. The only difference this time is that I'm not typing values directly into the boxes. I'm linking those component props to fields on the article bundle. So, if I save and publish this entity, it will be stored as a content template as a config entity in the back
end. not really that special in any particular way. It has all the same properties you would expect from a config entity. So, I'm not going to go through everything in detail, but specific things that are related to component tree are the dependencies, which is just a little bit of interesting thing is it lists all the components that were used on the in the component tree. It lists
the node type, the view mode that was used for creating of the template, but it also has the specific fields that are used for linking to the component props. If I would edit the template and unlink those props, those explicit definition dependencies uh would go away. And that's just pretty cool, I think. So, the component tree property on that YAML file of the config entity, uh there's
two ways how it's can look like uh when it's stored, when it's populated with a component tree. So, if you have a sequence of components that are not nested within each other, um in Drupal, they will be indexed array, right? So, they will be just array that is flat, keyed by integers. Once you convert that into YAML, it converts into sequence like this. So, it's a component
after component after component. Very straightforward. If you start nesting components, it becomes associative array. So, top-level components get their delta as their key, which is just an integer. But then nested components have uh interesting key where it's a combination delta of the parent, the slot they're placed in, and then the delta of that component within the slot. And if you start placing component into a component into
a component, that uh key just grows larger and larger, goes parent delta, slot, component delta, slot, component delta, slot, component delta. Um and that's what I'm trying to highlight here. It's still like in YAML, it's still a flat thing. It's just the keys indicate what is the data structure there, so we could build it back into the tree. And the rest of the properties are exactly the
same as the as in the canvas page content entity. We have the same UUID, component ID, version, etc. All of the same things. What's different is in inputs uh content page, for content entities, for canvas page, we can only have static values. So, if you have a text property, you type things. This is roughly what you get for long formatted text. But in content templates, because we
can link to the entities, we start seeing expressions. So, this is the expression. What it specifically does, it uh stores information that the value for this prop needs to be retrieved by drilling into node bundle article, specifically into the property into the field body, and into the processed property of that body. expressions and this the easiest comparison would be is uh tokens. If you think it's it's
like a token, but a little bit cooler. expressions can get way more complex and way more symbols, and I could fill easily the this line. I actually tried to make more complex example, and it was just too much to even try. But we never expect people to actually read this and uh or edit or write this manually. I think Wim can, because he's the one who came
up with this, but for mere mortals, uh this is not expected. This is a storage mechanism. So, Canvas code creates generates an expression, Canvas code stores it, and then loads it and consumes it. So, you can look at what things roughly do, but you don't have to. You're not supposed to. So, why are we not using tokens then in the back end of Canvas? Well, the very
simple reason is that tokens return strings. And when we started working on Canvas, the first type of component source we decided to support was SDCs. And we immediately hit the problem that SDCs can have props that are more complex than strings. SDCs props could ask for a string, but it could also ask for integer, boolean, array, object that consists of other things inside of it. And that's
where tokens kind of come up short. So, expressions was chosen as a more flexible solution for the same type of problem. So, before I go into static pro into the shape matching, I just want to briefly talk about static pro prop sources. So, what a prop source in Canvas is in general. So, just how like component in components just how components need source for their functionality, props
of components need source for retrieving a prop value. There are multiple different types of prop sources, and one of them is static. static is the the example that most commonly shown and I think in most of the demos. It's if you place a component that creates a text box, you interact with that form, type some text, hit save, this is what gets stored. Congratulations, you have used
static prop source. Interesting thing about static prop source is that well, they store an unstructured data input and it's it's good for short-term like pages, but it's not linked to any Drupal entity field, so you lose a lot of Drupal field why I wanted to speak about it just for a brief period is that we have a requirement that for every SDC prop, there must be a
shape like your prop in SDC must have must be able to match with a static prop source In other words, if you have a SDC component and you define the prop and we cannot match with the static prop, it means we cannot generate a form for it. If we cannot generate a form for it, you cannot provide input for your component. If you cannot provide input, it's
incompatible with Canvas. So, all SDC props must be matched with a static prop source. That's the minimum requirement for it to be compatible with Canvas. With dynamic prop sources, things are slightly different. So, this is a very extensive topic and I will cover it in very simplistic way. So, in a recent issue, Wim updated shape matching documentation and included this very helpful diagram explaining how shape matching
works in Canvas. slide has a link to exact shape matching file. If you copy all of its contents and paste it to the mermaid.live, you should be able to render exact same diagram. You can interact with it, zoom in, zoom out, and look at it. It's very useful. I find it quite overwhelming. And thankfully, Wim also included a very approachable example and explanation of the same concept,
and that's what I'm going to base most of my next session my next of my section on. So, instead of the diagram, imagine That's a shape sorter toy for toddlers. Given a block, find the hole that the block fits into. Pretty complex for a toddler. shape sorter can have many kinds of holes, and they can be of different materials from like basic shapes like a square or
or circle to complex like a square with slightly curved edge on one side. There's also variation of materials and colors. The game has very basic objective, match the shape of the block. If you're a parent playing with a kid, though, you can come up with additional rules like, "Hey, only place blocks that are red, or ignore all the blocks that are orange." Things like that. This analogy
fits really well with Canvas, pun intended. we can think of the box with holes in this analogy as a component with inputs. And the blocks themselves as Drupal structured data. We're trying to find which items of Drupal structured data could fit our in this specific analogy, we'll run through some comparisons. So, the holes of the box are component props. just like how the uh shape sorter has
holes to fit blocks into, component has props that needs values to fit into. And the shape of the hole really closely matches with the prop shape of the So, for example, like what what a prop shape is. Prop shape is a normalized representation of the schema of the component input. So, what I mean by this? Uh components components need to have primitive type, so like string, integer,
object, array. But, they also can have additional restrictions of what properties allowed into that object or if it's a string, what type of string it has to be. So, say you can have a string that's just a string, but you can also say that format of the string needs to match URI. So, you can only put URIs in that's that input. So, that's a prop shape. Prop
shapes can also be very vague or very very specific. There's two ways to go about it. So, and the toy blocks themselves in this analogy, they represent Drupal structured data, things like fields, right? So, individual specific prop block is individual specific prop source. it's the one that I've just mentioned in these static prop sources that just how components need a source com- for their component props need
source for their for example, you could have a block uh that is blue and square, and that would be say a node title. You can have a green round green peg that is a username, or something more complex like very specific shape block that is an equivalent of Unix timestamp for the specific date format. Uh just how blocks can be of different types, uh like wood or
plastic, canvas prop sources can always also be of different entity fields, entity URLs, or static And finally, the shape of the block represents the validation constraint placed on the piece of structured data in Drupal. For example, you can have that is a string, but maybe it has restrictions of what characters are allowed in that particular field or how how many characters are allowed. So, that's the restriction,
and it's equivalent to the shape of the block, so square block. So, this is the just terminology and comparison of things. So, in practice, shape matching works in two phases. the phase one is uh objective matchers, and in phase two is processing by subjective suggestion. So, matchers find every prop source that fits the prop shape. So, it's equivalent of asking, "Given this square hole, what possible blocks
can fit into it?" And then the second phase is the subjective one, that's more about about the context. So, if all of these blocks can fit a square hole, which one you should should pick up first? Which one that fits most right now? So, the matchers uh there are three services at the moment, uh services. There will be more. So, the entity field prop source matcher, it
looks at all the entity field definitions in Drupal and asks whether field can produce the right shape for a The answer is always boolean. It's either yes or no. So, for example, can a title field produce a string? Host entity URL matcher looks for host entity URLs, things like canon roots, etc. and sees if those can match the prop shape requirements. An adapter prop source looks at
all the registered adapters and asks if the adapters can transform data in such a way that it would match the prop And then, once we find every single match, so say you have a prop that all all it has is a very vague requirement of its string, and you place a component with that prop on your content template, what suggestor does, it filters out the things that
probably nonsensical. So, it looks for the most likely things you should you you want to use and filters out the things that are less likely. in the game imaginary in the game situation, it would be parent asking kid to ignore orange blocks, and for Canvas, it would be something that if you have component with a heading prop, you probably don't want like revision message or something like
that in it. You want a title of something like a node or or a field or a user. And then, the ordering takes all of those matches that already filtered out and goes a step further by arranging them in the most likely to the least likely option. So, if you still found 15 text fields that could fit this description, What order they should be presented to the
user? This is all very subjective and it's a best at best effort attempt to find the most common cases. it does work pretty good so now and it will if it will be extended in the future as well. So to recap, matcher finds all the prop shapes that can fit a Oh, so the matcher can So component declares prop shapes. That is passed to matchers. Matchers then
look for every sources of data in Drupal that can match a prop shape. Returns the full list which might be very very extensive. A lot of things in Drupal can be stored as string. And then suggester filters out that list and orders it in a way that it becomes useful to to the user. So in practice this means that just how like how a toddler with freakishly
long arm can find a square block to fit into a bucket, we can define a component that has an image shape hole or a prop. And we can place it on a in a component tree. we in Canvas can find all the possible and meaning like firstly find all the possible matches that could fulfill the requirements of that shape. But then we also filter out nonsensical ones
and order them it to be from to be most likely to to least likely. So for example, the image here refers to the image on the article node as the most likely thing is the the closest relative. And then you also have the user's profile picture and the user who edited the revision last profile picture. yeah. that I feel like that was went quicker than I expected,
but we have time for So, I don't know how this is going to work. So, please bear with me. Okay, I'm going to have to look at that screen when I'm doing things. Okay, it's done. I'm not going to go into anything difficult or complicated. All I want to show is the things that I and others at Canvas use for things. So, I've been working on Drupal
for really, really long time and this is something that I discovered really recently. So, it turns out if you in your settings.php, if you add this setting, extension discovery scan test and set the value to true, you will be allowed to install extensions from your tests. Extensions in as in themes and modules. What this means in reality is that I can install modules we are using in
Canvas for testing. I'm not a front-ender, so I don't really have a full set of really beautiful components to play with. But, these And these are not very beautiful. They're test mock-ups and pictures, but they do work. They have We have test proving that they work. So, if you all you want to do is to play around with Canvas, see how things function, place around some components
and sure, of course, I need to find something to place them on, but I think this is going to work. you can do things. You can place components, etc. So, this list of component because out of the box component canvas ships without any com- if you want AI com- like if you want code components, those are easy to access, but if you want SDCs, etc., there's a
little bit of, you know, work to do. But, what you can do, you can enable that setting. And you can enable uh canvas test SDC module. Did I make a typo? Cuz I I can barely see the screen. Is there a team Is there anything? Okay, it will be in the list of I I already have installed it. So, maybe this one's going to be faster, so.
What is happening? Okay, so. I just SDC. Maybe. There it is. Yeah, okay. Test SDC components. So, this module comes with a whole bunch of different SDC components. And if all you want to do is to play around, see how props work, how it's all in database, you don't want to fiddle with creating SDC definitions, playing with that, that's probably the fastest way. But, this is not
the main thing that I wanted to show. The main thing is something I haven't installed. So, we do have one of the test modules is called all Why? I think maybe it's installed. It wouldn't not be installed already. I don't think it is. You sure it might not? Oh, I think you I need to have dash. I need to have dash. It's all dash props. All dash
props. Yeah, there we go. So, I'm going to install this component, and while it's doing that, it's probably going to ask me to confirm it. No, it just did. Cool. So, what is all props component? It's It's a There's a module called all dash props, and it has a single component, and that single component contains every single prop definition canvas currently support and have widgets for. So,
if you add the for extension discovery and tests, you can to use this component to play around and see what can what is currently supported in canvas, and to the best of my knowledge, whenever new things are added to support, this component obviously gets updated. And you can then go ahead and go to your probably best place is the template it's not just static prop sources then.
Where's the layers? I think it's here. I'm just going to get rid of some things to make things easier. you can place all props component. It's not pretty, but it does work, and you can see every prop widget that we currently have. And you can also see exactly what fields and what data structures they currently match to. So, like this is for example, format, it's a string
within that has format of URI reference. So, it can be matched to image, it can be matched to user URL, user picture, revision user, etc. There's a lot of different options here. So, if you want to figure out, say, how, you know, how timestamps work, or how media library widgets work, this is where you can install and play around with things. if you want to find something
that is not supported, one of the best things to do, we have prop shape repository test. The class name will be in the slides. And it has a couple of methods. So, we have get expected storable prop shapes. So, this runs and tests whether all the prop shapes we expect to be able to store are actually storable. And also, there's the same method same same logic of
method, but for unstorable. I don't know if I can say Oh, no, I was at the unstorable. So, this one is storable. Sorry. And then the other one was unstorable. So, if you know if you have a if you're creating an SDC and you keep running into the problem that your definition is fine, and it doesn't work the way you expect it, one of the places to
look at for how things work or do not work, which things are supported and which are not, test is a really good place for it. And then the final thing I want to show is if you ever go through the problem of a new SDC definition to use it in and it does not show in Canvas for some reason, if you go to the appearance section of
Drupal, there's a components tab. It has two sub tabs. One of them is available components. So, the available components, you can manually can or disable the components that are present on your system. So, say there's a block that is really annoying you that shows up in a UI, you can just disable it here. There's also an ability to audit how something and where something is used. So,
if I'm going to go to my JavaScript and click on the drop down, I can definitely do that. Audit is going to tell me which content entities use these components, what revisions they are, things like that. Super useful if you're trying to figure out where you need to make changes or updates. But, if you're creating new component and you're running into a problem that isn't showing the
UI, the best thing to do is to check disabled and incompatible components. This is where Canvas stores every component config entity that was attempted to be created and failed validation. And exact validation errors that were encountered. And if a single component has multiple errors, multiple errors stored. So, you don't have to fix them one by one and keep refreshing. So, that's really helpful if you're just starting
up and defining SDCs compatible with Canvas. I think that's about it for the live section of this. I'm probably not even going to go into the presenter mode cuz it's going to be too tedious to do. So, these are the settings I've used and the name of the component definition for our props and the test that we've used. And I think we probably have time for Q&As.
I don't know when it's supposed to be ending. 5 minutes? Okay, so 5 minutes. Okay. I have a question about Oh. We're the components from the other locals and I think for example if you have a single delivery company and have a file for the week and CSS and just need to change only one line of Usually we should copy all the component to the same layer
and then just When you say one line, so the question is if you have a SDC component into the module and you want to update it. When you say one line, do you mean one line of wave, one line of CSS or one line of the actual prop definition? Because it the For example if I add one more CSS file for the component we should copy all
the component. This is really inconvenient. So is there a solution for that? I don't know if off the top of my head if CSS and JavaScript files attached to component change in the component version but you should be able to I I would guess that you should be able to make the change, clear the cache and you see your change change appear. It's the It's the pro-
component we should make a full copy of the directory. We can't just add one thing over the component provided by local. This is what he's talking about. He doesn't provide the module. You bought another module he's providing on and you want to change like add one more CSS file or JavaScript. >> Yeah, yeah, yeah. This to me sounds like something that should be added as an as
a capability in the SDCs themselves I Because because Canvas doesn't do anything special to how CSS and JavaScript is handled within SDCs. The component in Canvas just is a representation that hey there's this SDC, it has these props, these are the definitions of it and that allows Canvas UI to interact with this component. But we don't really do anything particular. You can't add or remove CSS or
JavaScript from SDC through canvas. You have to do it through canvas. So, if you need an ability to say have an alter hook that updates and adds additional things to libraries of SDCs, um maybe that's a valid use case. I don't know enough about that in first workshop to say yes or no, but I don't think it's something that can or should be done in canvas itself.
It's probably a thing for SDC in general. Yeah, and one more question about the for example we have and the text so you use the JavaScript component to display text. Does it render on the front end or on the back end? That's what you added the JS image and the text component to the field. I can I can try so the code components itself that I've used
for the for this particular demo is this. That's the code component in question. so for SDC So, I'm including formatted text from Drupal canvas. That's to the best of my knowledge and again, I'm a back ender. This is a set of extensions included with canvas for more Drupal-y things like formatted text. And all I do is use that imported formatted text and output text. And text in
this particular case is a prop added down here in bottom right. And for the prop I selected formatted this tell So, this selection here tells the component what type of the property is and what is shape. This is just tells JavaScript how it's going to be rendered. during the rendering as you see I would need to look into how specifically SDC is rendered, but I'm pretty sure
it's going to use the field widgets for rendering of canvas like a formatted text. So, it's the class will be most likely, give me a second. I think it's going to be like JavaScript component source, something like that. Is that storage? Is that source? I can't I can't see. That's storage. The question is mostly about who who renders this JavaScript in the browser or the server side?
Because if it's rendered by JavaScript, it's just an empty page for for search crawlers. So, I saw a lot of examples where the companies rendered on the front end. And this is not not a good No, so to the best of my Again, not a front ender, don't know much about this. I wish Balint was here. But, so this UI, what it does, it there's a browser
running a compiler that will compile minified version of this CSS and this JavaScript and store them as a as a properties of config entity. So, in fact, if I open the configuration here and do a single file export, we can see the Oh, come on. I can't I can't find things. It It would be It would be rendered on the front end for now. Uh I think
there's a road map. I can't remember when the the back end rendering >> Yeah, there is a road map to server side rendering the JavaScript components. Yeah, this is what I was talking about with Balint. We render this in PHP, but not JavaScript engine just for everyone to see. Right? So, why why is ECC using a lot of JavaScript components instead of server side rendering? Because it
produce ECC isn't isn't JavaScript. JavaScript script doesn't doesn't differentiate. >> Yeah. But it is a site by site decision whether you want to use STCs or JavaScript components. If you're really concerned about server-side rendering, you can use STCs which use our ours rendered on the server side. I mean, it's your choice. You can just disable don't give anybody permission to make JavaScript components. Are there any more
questions? I Do you guys have any plans to make all these bricks thing with blocks of the canvas? Because right now we have You could have a custom block like the great for images. You have to create a schema.json in our module, right? And then write the JSON to match the to match the signature, and then we can use this block in our components. Right now we
have to write We have things that are >> So, is the question are there plans for country modules or individual projects to provide their own schema definitions in JSON files? Is that correct? Yes, but it's something that's currently in the work in progress in core. And I think the main problem is the whole idea that you can link to the dollar or sign reference to some abstract
JSON somewhere. But if there is a plan for country modules to include their own Java their own schema definition, so not so things would not have to live specifically in canvas anymore. And then those schema definitions could be used by matchers and by shape matching But I don't know what the state of it. I knew I know that this was a work in progress at least a
year ago. I don't if any progress has been made on that. Yeah, but in the long term that is the plan because we can't possibly expect to fit every single reasonable prop shape just in canvas. There needs to be a functionality for individual modules to define their own Okay? Anything else? Okay then. So, the two QR codes, the one on the left is the feedback for Drupal
Con. I think for my particular session I actually haven't used it yet. And on the right is the QR code to with the link to And my contacts on Drupal Slack and on Drupal.org are there if you want to chat. Thank you.
