 Okay, yes there we go Cool, I guess we will get started. I'm assuming people can hear me. I'll speak up usually not a problem Cool, thanks everybody for joining you get this Bigger Yeah, so this is Drupal state and the need for a JavaScript SDK. I hope you're in the right place if you're not I won't be insulted But yeah excited to be here in in Prague It's been wonderful so far and it's really great being back in person So, yeah, I am Brian Perry. I am a staff engineer at Pantheon I am an initiative coordinator for Drupal's decouple of menus initiative, which we are so close to Wrapping up here at Drupal con which is great. We'll talk a little bit more about that I live in the Chicago suburbs in the United States. I Enjoy Drupal JavaScript and all things Nintendo. I Started playing Splatoon 3 which is a lot of fun and then I did buy I will admit that I bought an Xbox recently And I've been playing outer wilds on that which is a really fun. It's like a time loop game almost done with that too and also, yeah, semi recently bought a replica Ms. Pac-Man machine, which I have in my office for, you know, very professional work times and Yeah, I'm on the internet in a variety of places and would love to connect an internet with you And as I mentioned I work at Pantheon So the things I would love to thank Pantheon for is that one, you know sponsoring for me to come out here Also, some of the things that we'll be talking about today are things that Pantheon has Sponsored open-source work for which is wonderful And also, yeah, check out our booth. We have our front-end sites Our node hosting in early access a lot of what I focus on at Pantheon is working on starter kits and utilities So a lot of great open-source work happening there and yeah, I would love to know what you think but today we are going to be talking about a Library called Drupal State, which is a simple data store for managing application state sourced from Drupal We'll talk about why it was originally created why you might want to use it and why I think It or something like it is very important for the future of Drupal But also really, you know while we'll be using that as a framework We're also going to go on a winding journey through Drupal's supporting JavaScript ecosystem as well So buckle up So I talked about the I mentioned the decoupled menus initiative and at Drupalcon US a while back at this point We put together a hackathon Where a number of people got together to try to build JavaScript components that consume data from the new menus endpoint That's being developed in Drupal. So this is a web component I focused on building a web component because I wanted to learn more about web components We also had people who create things and react and view But yeah, you can see this Menu component has menu data from Drupal. We can expand and collapse things in the tree It's intentionally kind of stripped down so that the styles can be overridden If we look at the actual HTML file here, it's it's pretty simple. We have a custom element Gdwc-menu That stands for generic Drupal web components. I'm not maybe not the best at naming things But you know, you'll see here that there's some attributes we can pass in There's the branding so we can you know change the heading in the The menu the base URL is the root of the Drupal instance that we're sourcing data from The menu ID here if we change what the menu ID is we change it to the account menu Now if we expand it source new data from Drupal, we see the login link because we're not authenticated Change that back to main And then there also is a theme properties here. So we have horizontal we can instead do Unstyled Which literally just shows that there's no styling at all. It's just an unordered list and also if we leave it off The default styling just has you know, it lightly styled expand and collapse So this ended up being you know a pretty interesting proof of concept in how Something like a web component could make it simpler to create a component that plays nicely and generically with Drupal Getting into the details of it a little bit if you're not familiar with web components As in like the the browser apis They have a number of life cycle methods. This is the connected callback method, which essentially Happens when the component mounts So this is how we're getting the data from Drupal. So if the base URL and menu ID are defined we run this fetch data method and Here's the detail for that, you know, not super complicated We're taking the base URL and menu ID and using that to construct the endpoint that we're going to talk to and then we just use JavaScript fetch some light error handling and then we take the response and using a Supporting package that was also created as part of the initiative. We parse the menu data So it can be you know a little bit easier to work with represented in a hierarchy all that good stuff So, yeah, I do think this was kind of an interesting approach to You know show, you know how a component like this could be built that really took the work of Communicating with JSON API and allowed you to just kind of plug plug-and-play So after that we started thinking about, you know, how could we build other components in this library? But pretty quickly it was apparent that that approach Wouldn't really scale so if you imagine like a card, you know, which is card component something pretty common That might be a next thing to build If you have one card on the page, that's one API call, you know If we're using that approach where it's embedded inside of the component You already have your menu which might be another API call if you got 10 cards on the screen That's 10 API calls. You got a hundred cards or some sort of automatic scroll. You might be running into some problems So at that point You know, it seemed like there were some things that this this component library would need to be able to You know scale past just you know the menu component But also cases where you have you know an application or a page Where there's data that needs to be shared across a variety of components in a consistent way so What what did I think we needed? easy methods to source data from Drupal's JSON API so that They can be used across the the various components and then some sort of solution to be able to manage the Application state that we get back from Drupal that a variety of components can take advantage of And that seemed like not a crazy ask and something that you know as a as a JavaScript developer I could just go and PM install something that solves my problem and You know at the time it really didn't appear to be quite that easy so I looked at other projects in the community and For example Drugs, which is a view base project. They have their own custom JSON API client which uses Axios And it uses the view extor which makes sense because it's a view project and then next for Drupal This was a while back. So it was prior to the 1.3 release And at that point next for Drupal had a bunch of individual helper functions and Then more recently they have also introduced their own client Which definitely has some similarities to the this project that we'll be talking about today There's a lot of overlap in what the two clients do There were other SDK libraries like Drupal SDK Drupal JS SDK Who knows which ones which if any of them are official Drupal things? and then on Just custom builds custom decoupled builds, you know I've been familiar with people just rolling their own in general I don't know if that's been your experience, but you know people write their own fetch things They they you know write their own methods to handle state a lot of solving this problem over and over and over So yeah, what what would we need to stop solving this problem repeatedly? So Something framework agnostic, you know if we're trying to think of something that could apply Broadly to people who are using Drupal in a decoupled architecture Also the ability to use just the utilities your project needs I I do think that there can be some useful defaults here, which we'll talk about But there are going to be situations where maybe somebody just wants to use the fetch utilities or they want to use their JavaScript frameworks state management Utilities, maybe they want to use Redux or something So if the individual pieces are exposed people can just use what they want and use it with their state management for example But also at the same time I do think having some sort of out-of-the-box solution for handling application state Could be really useful. So, you know people don't necessarily have to think about that or customize that Unless they want you and then also, you know as I started thinking about this. I also started thinking about JSON API in general and Like could Interacting with JSON API be friendlier for JavaScript developers like what is the experience of a JavaScript developer who may not be familiar with Drupal? Who finds their way into getting data from JSON API? So, yeah specifically thinking about this from the perspective of people who maybe either aren't familiar with Drupal or aren't Specifically familiar with the JSON API spec or Drupal's implementation of it So, yeah the the kind of best way I think to to explore that a little bit is just through some quick examples so the For JSON API, I assume many of you have probably interacted with JSON API, but I'm not gonna assume that everybody has So you may know what the endpoint so this example is getting recipe data from the you know, umami demo profile As a developer you may know what the recipes endpoint is but you might not if you're not familiar with JSON API or Drupal's implementation of it or Intimately familiar with the site that you're going to be getting the data from You may not know that endpoint so the root of JSON API Gives you an index of all the available endpoints So you may have to first fetch that To be able to determine what the recipes endpoint is which we're doing that here and then at that point you can fetch that from that endpoint and then we get all the recipes which are under the the data object and So if we wanted to for example access the instructions for a single recipe the response that you get back from JSON API It also definitely does have some Drupal specific things inside of it, so Many of the fields are under attributes rather than just kind of at the top level so if we wanted to get the instructions it would for the first data Entry in the array it would be attributes dot field underscore recipe underscore instruction dot value and then think of a situation where Later you needed to get so that the root recipes endpoint will get you all of the recipes If you in the future you needed a specific recipe you could fetch with a UUID here to get just that recipe, but that's really a redundant API call At this point because we already got our recipes So if you somehow store the first response so in this case, you know, we're just storing it as a variable You can get that existing data In this case, you would have to filter through The recipes that you have by ID and find the recipe that matches based on the ID to be able to get that particular recipe Again, not you know three lines of JavaScript, but there's still three lines of JavaScript that need to be written and then going into some other examples This is if you want to deal with a Referenced entity in Drupal so something simple here just a taxonomy term. I really do not want to install Firefox So The we want basically just want to print out the recipe category for this recipe on the screen, which is main courses So we know the endpoint that will give us this particular resource JSON API and Drupal's implementation of it. There are a number of query string parameters you can pass in to do things like include related data filter sort, etc But you know people have to be familiar with this structure, but we can say include Field recipe category to get the recipe category We fetch that we'll get our response back But how the response comes back Again for somebody who's not familiar with the JSON API spec. This might take a little parsing to figure out But under relationships, let's see we have our recipe category So under relationships, we just have the ID of the recipe category But then by saying to include the recipe category under included we have all of the included recipe categories for this so if we wanted to to Get this particular recipe category. We would have to filter all of the included values Because you know in this case, there's just one recipe category But it could be multiple and that set of included data is shared across the whole response So if we were getting all of the recipes that would be all of the categories For all of the recipes so we have to look it up based on ID So again, we have to filter based on the ID to get the correct category and then to actually Get the name it's attributes dot name name is under attributes in the category. So All that to say all the data is there, but it's a pretty long walk to print main courses on the screen And then also, you know another common issue is Overfetching with Json API so by default Json API gives you all the stuff which is definitely useful But oftentimes like think of a teaser You know or you know a grid of items you might only need a few fields You might only need like three fields rather than everything so being specific about what you get back in the response We'll have a pretty substantial impact on your payload So if we want to do that with Json API we can there's again things that we can add to the query string So if we include field recipe category We're gonna get all of the fields on the recipe and all of the fields on the category, which we don't need So again thinking about like a teaser, you know, maybe we need four fields on the recipe So you can add Fields and then the entity type here node recipe and then list out the fields that you want So if we do that for node recipe, we can say title difficulty instruction and category That still gives us more stuff than we want because We'll get just those fields, but the recipe category the referenced entity will have all of the fields So we have to refine that further and say fields taxonomy term recipe category. We just want the name So again, all of the tools are here But you know it takes a little work to structure a request that is going to give us just the stuff that we want There is a great package Drupal Json API programs that simplifies this quite a bit Add some utilities to construct these Json API requests Highly recommended, but you know again, it's something that you have to know exists So this is just seeing that example on its feet a little bit So we have our URL that we constructed we can fetch it But still even you know, we've gone through all that work to be really specific about what we're getting back We still have the structure of the Json API response some things that are under attributes our Relationships and the included data that we have to navigate so It still may be not as clean as as we would expect How's everybody doing everybody doing good doing good excellent head nodding great Cool, I know where you know lunch is next so everybody's level Cool so the talking about over fetching definitely leads to graph QL and Graph QL within the Drupal community So graph QL it's a different query language, and it's really good at solving this problem of of over fetching Because in your request you essentially describe the shape of the response that you want You specify all the fields exactly how they would be structured and the API responds matching that shape that you specify so I Am not heavily involved in Drupal's graph QL ecosystem So this is a my somewhat uninformed overview, but I would say graph QL and Drupal's relationship is it's complicated so One thing is that the graph QL module is a contrived module. It's not in Drupal core JSON API is in Drupal core, and again I'm trying to you know think of this problem from the perspective of people who might be new to some of these things And then the graph QL Module itself went through a pretty substantial change from version 3 to version 4 Version 3 works pretty similar to JSON API where you enable it There's not a lot of config and it essentially exposes a schema for all of your Drupal data So you can just start querying things Version 4 on the other hand does does not do that. It doesn't automatically generate a schema You have to write custom code to define your schema. So pretty big architectural difference My understanding is that the you know the reasoning behind that which you know is valid Is the the version 3 approach would essentially leak a lot of Drupal isms into the API So it probably isn't representing the ideal API structure for people and The version 4 approach really allows people to tailor the API to their specific needs But that comes with a really big cost in that you have to write custom code to do it And I definitely see that as as a barrier Experimented with some things around this in the Drupal State Library. This is kind of jumping head a little bit but it fits here we Did add functionality to use like lightweight graph qo graph ql queries against JSON API There actually were some existing libraries that handled that And it was you know nice really nice developer experience But we found it was a little difficult to maintain that path along with traditional JSON API Communication and then also some of the libraries that we were depending on really weren't maintained anymore So we we've deprecated that feature recently But also within the the community Jesus at octahedroid a friend of Pantheon The octahedroid team has been working on the graph ql compose module Which actually is a supporting module that will allow you to automatically generate a schema for graph ql So that kind of allows us to have the best of both worlds. You want to build your own perfect custom schema You can do that. You want to just generate the best representation of your Drupal data. You can do that as well And for the future of you know, this library, you know with with that problem being solved Like I could see us adding some sort of like actual official graph ql support in the future So back to to Drupal State and how it solves some of these problems that we talked about or at least tries to It is it's framework agnostic. It's vanilla JavaScript So you can use it with whatever JavaScript framework you want or no framework at all It's universal so it can run on the server and the client It the first request that you make to get an object from Drupal It will make an API call If it doesn't have that data already and then it will serve future requests from local state So it caches the response. So if you wanted to get an individual recipe, for example, it won't make an API call for it by default also the response is deserialized and flattened and a little bit simpler and The all of the underlying functions and utilities are exported and made available from the library So if you wanted to just use the pieces here, you could So we'll look at some quick examples just to kind of get a feel for the difference If we were to use this library, so we import Drupal State and then create an instance of the store And we provide the the API base There's you can also provide an optional API prefix if your root is not JSON API and you've customized it and then Getting all of the recipes in this case is as simple as as this one line so a wait store and then we call get object and Pass in the object name node recipe in this case and then this is what the Data that we get back looks like you can see here. It's deserialized and a lot Substantially more flattened Including things that are referenced entities. They're still up at the top level, which we'll look at in a second and then if we Next needed to get in or later needed to get an individual recipe and new the ID We can use get object again and provide the ID and in that case It's going to see that it already has data for that recipe and return that from the local store rather than making a request to JSON API so can cut down on API requests pretty substantially if you use that caching and And then this is looking at the the reference entity taxonomy term example that we looked at The Drupal JSON API params package is also a dependency of Drupal state So we're going to use that here. We create our store We create an instance of Drupal JSON API params and then use its add include Helper to add the recipe category And then when we make our get object request for this particular recipe we just pass in that Params object you can use Drupal JSON API params if you'd rather just construct the query string yourself You can do that too and just pass that in either approach works and then with our response back if we wanted to get the recipe category it is Recipe category is an array. It can have multiple results, but it's just the you know in this case. There's just one so field recipe category Dot name Yeah, here is the field recipe category Yeah, kind of at the top level and you just have the flattened data under the recipe category So a little bit easier to get at the data using these deserialized responses and then We've also been working to support some popular Modules in the JSON API ecosystem. So this is an example of support for the the decoupled router module which lets you look up a an entity in Drupal by resolving the path alias, so In this case, you can use get object by path Provide the object name and the path and the response that you get back is the recipe that Resolves to that path So handles a handful of things behind the scenes to do that, but gives a pretty simple API to make that call And then You know as I mentioned we also expose all of these utilities So if for example, you wanted You know this translate path utility that we use to talk to decoupled router You could instead just import translate path and use that to your your heart's content So that that method takes the the The API endpoint for decoupled router and then the path that you want to resolve So and here the response that we get back is just exactly what the decoupled router endpoint returns And this is an example this is the code the TypeScript code for that Method it's not super complicated But you know, it's not something that necessarily needs to be written over and over You know if we need to to communicate with the decoupled router endpoint so that you know again a quite a long tangent we started by looking at that menu component in the Generic Drupal web components project and then Realize that there was a problem that we needed to solve to be able to make it more realistic to be able to have a bunch of components that share Drupal's application state So that actually allows us to now go back to the generic Drupal web components And now that we have some of these problems solved in a generic and kind of reusable way We can focus on the things that make this design system for example More unique and you know, hopefully it also allows you within your projects to do similar things. So Here this is using the card component in in the library Again working with the same set of recipe data So if we go into the markup here We created a couple of additional web components that use Drupal state and the utilities that we've been talking about So there is the store web component and the provider web component So the store really is just an interface to the Drupal state store that we saw some examples of Pass in similar parameters there including our API base and then any of the provider components within it I basically allow you to interface with that store And make requests so we this is really similar to like the get object calls that we saw So here we're saying that we want to get a recipe with a particular ID Pass in some query string parameters for JSON API and then now You can use a HTML template inside of that provider And it just has access to the scope of the provider that it's in so it has the data that it gets back from the store And that template is an HTML template so it can be any markup So as you'll see here towards the bottom, we just have you know regular headings and a paragraph But we can also use a card component from the library It could also be any web component any custom element So for example, there's the outline project It's another Drupal friendly design system You could use outline components here within your template and just pass in Drupal's data or you know, whatever you would like so Couple other examples of what's possible with this So, you know, we have kind of a twig style double curly brace to reference the variables here So right now we just have a placeholder, but I can just do title To get the title from this particular recipe deep Mediterranean quiche and You know in this case we we probably don't need this anymore But yeah, so we have one result if there's one result it renders out that template if we remove the ID so we get Multiple recipes. It just iterates over the template multiple times. So we see a bunch of recipes here now rendered with the cards and You know, we can even just use traditional styling. We could have a style on it here in the template if we wanted to And if we do that we can add, you know, three lines of CSS here to start a two-column grid We have our cards in a grid and then just kind of a fun little additional trick here the generic Drupal web components library uses a package called open props which adds A really great set of design tokens that are just CSS custom properties So we can use those here as well to add, you know, some more styling tweaks to these cards So change the color of the headings add a drop shadow rounded corners all that stuff so You know again really long walk to get get over here, but I think that these two having just a Broadway that we can get data from Drupal that can be shared across all of these components in a consistent way Really opens up some some interesting possibilities Yeah, so Given all that, you know a question is, you know, where where could we go from here and and I performed an extremely unscientific survey to kind of get a feel for how Drupal stands in the wider JavaScript ecosystem which was searching stuff on npm and You know, this is a little outdated the screenshot at this point, but if you search for Drupal on npm the results are Maybe not exactly what you expect So, you know first result here is an implementation of parts of Drupal's the user slash access control API There if we do scroll down a little bit there is Drupal SDK Is that Drupal's official SDK? There are other Drupal SDKs there So yeah, it might for somebody who just searches Drupal, which I could easily see a JavaScript developer who says it was told They have to work with Drupal doing this It's a potentially a confusing set of results Maybe you know that you can look at organizations in npm. You might want to see what Drupal as an organization has This is currently what we have under the official Drupal namespace on npm Two packages that are used by core The exciting news is that hopefully maybe even this week There are two more packages that will be publishing under the Drupal namespace coming out of the decoupled menus initiative So doubling the number of packages here But yeah, I mean looking at this today, you know, it might not even be Clear like how Drupal would use those things search for WordPress This is more in line with what I would have anticipated searching for Drupal First thing is a client for working with WordPress and then I see a bunch of things under The WordPress namespace. I think part of what drives that is the the block editor in WordPress in that it's react And this is probably a lot of things that WordPress core and the block editor use but still this Makes more sense and seems a little more JavaScript friendly to me And then take something like Contentful, which you know, it's not the perfect one-to-one comparison because it's an exclusively headless CMS But people who might be working with Drupal might be familiar with Contentful or worked with it in the past and you know Obviously, there is a really clear client for Contentful here a bunch of things under the Contentful namespace You know, it has to be like this because this is the primary way to interface with Contentful But again compared to the results that Drupal gets it's a it's a different story So how could we improve this? So I as I've probably tipped my hat to a little bit already I think it would be good if Drupal had a larger presence under the Drupal namespace on npm. I Do believe whether it's this or something like it in the future That Drupal should have some sort of official client or SDK And then also, you know a little bit of an offshoot and something that kind of came out of the decoupled menus initiative but We don't really have any documentation on Drupal.org about decoupled Drupal and this approach to building sites And I think that would be really useful both for the community But also to you know make it clear that this is something that you know is important to Drupal and the community So some things that's possible next steps some things that are in progress So I would love to see us promote more things into the Drupal namespace on npm. There are two packages from Coming out of the couple menus initiative We've been talking with the JavaScript maintainers about getting that done So that will actually start to expand, you know I have wondered something like that Drupal JSON API params package that is used by a lot of decoupled Projects like something that has found success within the community Maybe there's a case to move things like that over to the Drupal namespace in the future I also did create a an issue in the ideas queue a little while back about a proposal to You know formally try to start a process to build SDK or client like utilities in Drupal If that idea is interesting to you, I would encourage you to check in on that issue leave comments There hasn't been a ton of traction around it I don't know if it's because I haven't been able to really drive it or if that shows that people aren't interested I don't know But yeah, check that out and then within the decoupled menus initiative We definitely tried to keep the scope down to just decoupled menus But there was a lot of early thought around like what could Drupal wide decoupled Drupal documentation be Early outlines and things so this is a meta issue to try to move that forward I'd love to see something that happens in the future is for people to contribute to actual full decoupled Drupal Documentation and there is a home in the Drupal developer guide for it. So we've taken some initial steps there and This is the part where I somewhat irresponsibly Share thoughts on the trees note yesterday and some things that kind of came up in this this neighborhood very recently But for those who saw the trees no or didn't Towards the end trees talked about things that we can do after Drupal 10 is released and kind of Encouraging to try to push forward in the area of innovation again and some things that came up under that what were to keep investing in headless and the idea of there possibly being some sort of official Drupal the JavaScript front-end reference implementation Which are both things that that I unsurprisingly supports And also yeah the call to action here that these are things we could start in on now and a lot of this stuff Already exists. So I think a lot of the groundwork For you know a client or common SDK utilities, obviously, you know projects like this or the other Clients that have been out there. There's really a lot that exists today Where we could try to bring some of this stuff into Drupal itself somehow an official capacity and This is an old slide from a past trees note where he introduced the idea of the decoupled menus initiative You know hurts a little bit because you know, it took us a long a long time to get to that flag up at the top way More than it should have But you know, we certainly learned some interesting things along the way and and I feel like if you squint your eyes a little bit you squint You know you have a similar mountain for you know thinking to the end goal of having a reference implementation where Starting to build out these utilities Will be useful to the community but could be kind of underlying support for this Maybe an official client is created and then perhaps that reference implementation could actually use these things That were built, but you know, it's only if you squint So Definitely related contribution efforts going on this week. I'll I'll be kicking around the contrib room this afternoon I'll be there most of the day tomorrow Would love to talk about the stuff more. There's issues in the Drupal state issue queue if you're interested There's that ideas issue for the idea of an official Drupal client. We'd love to get people's feedback on that For the couples menus initiative We are hopefully going to get the actual core menu endpoint merged this week. We're so close fingers crossed And there's also some things that we're going to do tomorrow around documentation so if anybody would be interested in trying to wrap up or provide feedback on the decoupled menus documentation or look at what we could do in The future for the couple documentation would love to talk about that and there's also the generic Drupal web components project in general If you're looking to experiment with web components, that would be a great place to do it You know open to any and all contributions and there is almost a limited amount of things that we could In fact build an offer in that Yeah, and I think that is it have a little bit of time for questions And also thanks Were there any any app magic app questions? People here if they have questions can also hop up to the mic over there Yeah, so the the question was I mentioned parallels between next for Drupal and Drupal state Can I you know go into the the differences? So? first off next for Drupal is a kind of larger scale project and and Drupal state is just a piece of Interfacing with json api so next for Drupal is a it also has a starter kit for next js example page templates other utilities but next for Drupal also does have to communicate with json api and somewhat recently as the 1.3 release a few months ago. They also added their own client They had a helper utilities that did a lot of the same things But now they they have a client as well and looking at the two clients They're accomplishing pretty similar things, you know, there's only so much you can do with json api So it makes a lot of sense that they would be doing similar things So from the perspective of this project, I would love to see a Situation where we might be able to start abstracting some of the underlying utilities underlying things that those two clients do That would actually be under the the Drupal namespace and that these clients could start instead consuming those I think that would be a great step in the direction of trying to not have these competing clients And from my perspective, you know, I like I just want there to be a good solution here I don't necessarily care if it's mine or somebody else's The other thing to mention about next for Drupal It is obviously really focused on both next and Drupal, you know, the Drupal part makes sense We're not gonna get out of that, but there are some I guess the better way to say it is both next and react So there are some next specific concepts baked in a little bit some react specific things like hooks So something like Drupal State is intended to be framework agnostic So you can use it with react or view or whatever JavaScript framework is cool in two years And I think that is important for Whatever we offer in this space. I don't think it would be a lot of work to unwind those You know react specific assumptions from next for Drupal's client But I don't know if they'd be interested in doing that Yes in the back Yeah, so I mean the short answer is that that right now this this library does not have you know an answer for that We can get back all of the data and store it locally so that you could build search utilities on top of it You know, I definitely do see a world where we could have supporting utilities try to make search easier But they're really there really isn't anything today, but I think really though the way Well, one of the ways to solve that is really just being able to have the consistent way to manage application states and Trying to you know limit the calls to search where you can that's a piece of that puzzle But yeah, we don't really have an answer for that right now good question though Anything else? Yes So the the question slash comment was that in the past he saw an amazing react admin theme And you know could something like Drupal state make that possible. I mean it would definitely be a Small piece of the puzzle, you know, this library doesn't have opinions about rendering anything really But yeah, I do think that You know again, it's one man's opinion But if there was a world where we had either a reference implementation or started to You know incorporate more react in Drupal itself and it needed to talk to Drupal's APIs Just a you know a client or a common way to interface with it would be part of that it would be kind of underlying Technology as part of it, but it also won't magically make a cool admin API, which I know we would all want Yes Me too Yeah, so I did offhand mention and this was feedback friendly feedback I got this week as well that that's probably not a good name for this library and it is confusing for that reason So yeah, the something to think about is maybe if there is a better more accurate name for this And the reason that it was named that is you know thinking about JavaScript application state and that was the problem I was trying to solve initially But as it evolved, you know, it's not necessarily exclusively about that problem It's about utilities to interface with JSON API. So it's kind of grown out of the name But yeah, good feedback. Thank you Anything else cool in general I'm around and I would love to chat more but thanks everybody. This was very fun Enjoy DrupalCon