Taking HubSpot to the Next ‘Elevate’-ion: A React-Powered Showcase

When dreaming I'm glad you and all the world Time and time again Earth's own rise I fight still sleep Want to leave the comfort of this place Cause there's a hunger Longing to escape from the life I live when I'm away so let's go there let's make our escape Come on, let's go there Let us can we stay can you take me higher to a place where I'm lying at the sea can you take me higher to a place where boring will seem Although I would like a world of change it helps me to appreciate those nights and those dreams when my friend I sacrifice all those nights if I could make the earth and my dreams the same the only difference is to let love replace all I hear so let's go there let's make our escape Come on, let's go.

There.

Can you take me higher to a place where I see can you take me higher to a place where.

Falling street so let's.

Hello Internet, how are you all doing? So welcome to the newest developer Hug.

And.

I think it's one of the most anticipated topics today.

So.

Today is going to be the new REACT Power Showcase and also news about the Elevate theme. So for that we have BJ and John from HubSpot and also I think we got a few HubSpotters in the chat. So welcome y'.

All.

And for the agenda, we're gonna start with the Changelog with Brooke. Then John will take over and show you a bit about the new React development. And after that we are diving into Elevate with bj. And last but definitely not least, the Roundtable discussion and Q and A.

So.

Just drop all of your questions in the chat at any time and we will answer them. So Brooke, the stage is yours.

Awesome. Thank you so much, Anton. All right, y', all, it is the end of the month, which means that it is time to talk about some of the stuff that we've been go. We've been doing here. And so if you are not already subscribed to our changelog, make sure to subscribe and it will get directly to you in your inbox every time that we put out something on the new change log. And you can also go to our Changelog page and see all of the updates. So let's go through and talk about some stuff first. I just, I plugged this last time, but the ecosystem mentorship program is still open for applications and it will be open until next Friday, March 7th. So I know that we have a lot of people here who have been in the ecosystem for a long time. So if you want to give back to the community, I definitely recommend that you look into becoming a HubSpot mentor this time. This is a nine month commitment, so you know this is going to be something that will take a little bit of your time, but it's going to help the overall ecosystem. And if you just want to give back and you have time, become a mentor. Make sure to sign up at the link below and we will hear, we will let you know after the applications close next Friday. So all those people who've been in here long time, HubSpot devs, I know some of you all have already submitted your apps. That's super exciting. But for anyone who has not, you have until next Friday. Next up. So this was our public beta, but the reminder that the automatic deactivation of exposed tokens is going live in about a month. So starting on April 7th, any of your tokens that are exposed in public GitHub repos will be automatically deactivated so they'll no longer work. And this of course is aimed at enhancing platform security by mitigating the risk associated with leaked tokens. So the tokens that are going to be affected by this update developer API keys, personal access keys, private app tokens and SMTP tokens. So what we suggest doing is if you have any tokens that you know have accidentally been put into a public repo, just go ahead and you know, take those out and rotate some new ones in. And don't, don't do that. Use your, use your.env and your.gitignore. make sure that everything stays safe in whatever project you're working on and then if that does happen in the future, they will be auto deactivated. So if you find something breaking that could be the reason why. So just a PSA about that. Next up we have a new API alert. Oh my gosh, so exciting. Tax Rates. This is going to be so good. This is a read only API so you can't send data to this, but you can grab the data using this API and this will allow you to manage commerce tax rates. You can now fetch manually configured tax rates and apply them to line items for deals, quotes, invoices and other commerce tools which enable programmatic tax calculations within your integrations. And the tax rates API provides you with the ability to do that like I said. And so please note that this API supports manual tax rate and does not expose auto calculated sales tax functionality which is currently in beta for payments users. So if you do anything Commerce Hub related? Definitely. Make sure to check out this new read only API. Next up, we have an update for the Exports API and these updates are going to go live starting tomorrow. So take note of that. By allowing multiple associated object types and optional features that improve performance, this change improves alignment of the API exports with the in app experience. So we've got a new Boolean field called Include labeled associations. We also have new functionality for Include primary display property for associated objects. The default behavior of get associated object type is going to change. This field will default to true, but for multiple values the default will be false. And lastly, we enhanced the field associated object types. This now supports a list of up to four associated object types. So again all of these changes are going live starting tomorrow. And lastly, unpublished custom workflow actions are now visible in your dev test accounts. So you can now see and test them in your dev test accounts. And this will allow you to do faster iteration, better debugging, and a more seamless development experience in test accounts before rolling actions out to production. So when you're editing a workflow in a test account that has this installed, that has installed an app from the same developer account, unpublished custom actions created for that app will be visible in the Test accounts workflow editor. And this will only apply to test accounts and apps created in the same developer account. So if this app was created in a different developer account and you're testing it in a test account that was created in a different one is not going to show up. So you have to do it within the same developer account. That's all I have for you all today. I'm going to pass it off to John. John, take it away.

Thank you, Brooke. Okay everybody, I've got a couple new updates that I wanted to share about the React dev flow. One of them is available today and one of them will be launching soon. So let's get into it. One of the things that we working on on the CMS React side is finding a better or a faster way for devs coming to from Hubble to CMS React to get started quickly with a project and React modules. So we stood up a NPM package that allows you to do just that. So let's walk through it. So as you can see in my terminal, I'm going to run a command called Run mpx create CMS theme and this will kick off a process for us. And there's a few prompts we're going to answer here that's going to help us configure your starter theme. So we have. I'm going to call this dhugtheme. It's going to ask me if I want typescript or not. I'm going to choose yes, we love Typescript. Over here. It's going to ask what directory do we want to create our theme in? And this defaults to the current working directory. So I'm just going to hit enter here and then you'll see we have some prompts or some logs here that explain what exactly we're about to do. So we're going to generate a TypeScript CMS theme called Dhugtheme. We're going to install the latest version of the HubSpot CLI on your machine. We're going to install all the dependencies for your project. So as a reminder, there's two potential sets of dependencies that a project can have. Your root level dependencies that are a lot of like your dev tooling, like you can think like eslint, prettier things like that. And then we have your, your react, your project theme dependencies. So these are all the things that are running your modules and templates and such. So we're going to install that and then we're going to also authenticate your HubSpot account by generating a HubSpot configuration. So I'm going to. This all looks good to me. So I'm going to proceed and we're going to go through a few things. So we've initialized a starter theme and now we're going to go through the dependency install. While this is going on, I'm going to open up in the side panel. We don't really need to see these logs for now. We've copied over this starter theme. So I just want to quickly walk through what we have here. As a reminder, some of the key parts of a project are a couple config files. We have our hsproject JSON which is pulling in that value from the prompt or the hug theme. Then if we dig into the source here, we have our theme JSON which is labeling our theme. Very basic setup, but this allows us to go from nothing to running a dev server and or uploading this to your portal. You can see in here we have a couple of templates and a single REACT module to use. Once this finishes, it's all done. I'm just going to jump into this real quick. NPM run start to kick off the dev server. So just take a moment and then I will open up the dev server.

Right here.

It opened it up in the wrong window. There we go. So now we see we have a locally running dev server from that script with a single module that has some links to our to our stuff. So this is available today. Dennis will share a link to the NPM package that has a readme that with some more information about what to expect from this script. But hopefully this will be a good building block for devs wanting to start a new project or for devs coming over from Hubble to be able to build upon this starter with all the baseline configurations together for you. Sweet. The next thing, this next thing that I'm going to demo is not currently available. Actually let me kick off, while I'm talking about this, let me kick off this dev server. This is not currently available today, but we will be launching this soon. This is a reimagining of our dev server UI as you previously know it. So you can remember it's gone now. Let me go back, see if it still. Yeah, perfect. So this view right here, we've updated this to be a little bit more helpful. So once this dev server stands up we can start walking through some of the details of that dev server UI which hopefully will add some value to your workflow. And there's a couple new features that aren't weren't currently available that are exposed here. So again this isn't available today, but it will be. We will be launching it soon. We're just doing some putting some final touches on it and polishing some things up before we send it out to you all for this. Why this is taking a while. I'm standing up this. Our preview session is taking a bit because I am using the elevate theme to do it. So we have a lot of templates and things that we're having to prepare as we get ready to show this. This way we can have a more full looking depth server UI to walk through some of the parts. Sweet. So here we go. This is the new dev server ui. So once we launch this, this will be what you see. So let's walk through some of the parts. So we have this header area here with the name of your project, some quick access to things like Portal id, how many modules and partials are within this project. These CLI commands are being pulled from your package JSON. So any CLI commands that you put like scripts in your package JSON we will pull over here just to simp for like quick copy and paste action which hopefully will be helpful. And then a couple links here at the top to the Slack community, how to get in, get signed up for that if you aren't already. Some of our getting started docs and then the more interesting parts here are these table views where we have our modules. We keep going down, we've got partials, this project doesn't have any. And then templates are all in here as well. So this gives you a high level view of what all is in your project and hopefully a more accessible way to get to all of your things and preview them while you're iterating and building your CMS React projects. So let's focus first on this modules table. You see here we have a few columns. We've got the type which is React. You can see here I have a Hubble one as well. This works both with Hubble and React. A lot of you all are going to be migrating projects, I guess hopefully you all are going to be migrating projects from Hubble to React. There's going to be this intermediary state for a while. This allows you to iterate both your Hubble and your React modules at the same time. At least see what's in your project. We have this, if you click I'll Click on this heading 1. Here we have this idea of metadata that we're allowing you see. So when I click on this and I'm zoomed in a little bit from my browser, so the styles are a little funky, but if I click on this, we now can see where this lives in your local directory. Any pages that this module is being used on. So you see right now this is just being used on one page. If we click on this, it would take us to the HubSpot app to see said page and then our fields JSON associated to this module. So you get to get a glance see that if I scroll all the way down, we also open it up. If you're using VS code, this opens it up in VS code for you. So quick access to that direct file, hopefully that's helpful. The next thing we want to talk about is I guess we'll look at VUE Local version first. The Vue Local version is the local device UI that you've known before, where if you click on this it opens up just the module in isolation so you can iterate and make sure you have all the parts to it, make sure the markup is all right, all those great things. So that's all the same. Nothing new there. But we now have this View an app button which will allow you to view the module in the context of the of the like, similar to the Design Manager previewer of a module so you can see the form next to the module so you can get an idea of what the marketer's experience is going to be like. So if I click into this, we'll see. Now we have our our module with our fields and so you can see this in the form which hopefully allows you to iterate on your marketers experience. Now the cool thing about this is not that you can view this in the form, but now you can iterate on these fields and see them locally. So I'm going to uncomment a couple things on this side on my code. These are just local changes, they have not been deployed to my portal yet. I'm just going to save these here. You can see now I now have a local only field right here and then I've got my it's rendering over here on the page. This allows us to not have to hop into the app, the HubSpot app, to work on these modules and make sure that the fields are showing how we expect and what the marketer is expecting. We can do this all locally now. And one caveat to that is we must initially do an HS project upload to get those module definitions stored in our database before we can render in this preview. So you do have to do an initial project upload of a module and then once that baseline definition is up on our side, then you can start stitching in your own local changes that will show up in this view. So there's a little bit of a step there and we have some affordances in the UI to help you know, when that hasn't been done. Cool. So hopefully this is a helpful improvement. We think this is pretty neat going back to here. There's one more thing I want to talk about was these template previews. So we have this today where you can view a Hubble template locally with HS theme preview. So we've brought that over into our dev server ui. So if I click View local version, this will open up the template. And the nice thing about this flow is that we can view our modules instead of viewing it in isolation that maybe doesn't have all its styles. If it's inheriting styles from a global style sheet or something like that, we can view it in the context of template. So it does have all those styles to verify that the module we're creating is working how we expect within the context of the actual page template. The cool thing about this is we are also stitching in those local changes into these templates so you can do the just the Same like in the module form that we just showed you can do the same thing where you can validate on a page with local changes here as well. So you can see I have my locally added field showing up here and after I remove should go away once it refreshes right there it goes away. So now you can do the both in the module edit form to verify market experience and also ensure that your modules are rendering as expected on a page with all of the styles and extra JavaScript whatever the whatever additional context it needs to replicate a real life scenario. Perfect. So that is all that I have to demo here. Again this is not available today, but we are nearing the end of the work here and we will be launching this soon so you all can take advantage of it and give us some feedback. On that note, I will be wrapping up here and I will pass over to BJ to dig into some Elevate. Goodness.

Heck yeah, that was awesome. Thanks John. So My name is BJ. I'm a senior developer here at HubSpot on the content Assets team. So largely I'm a part of the team that's building a lot of our default assets. Love them, hate them if you love them. I built them if you hate them. They were here before I came so hopefully that, you know, don't ask me questions about those. No, just kidding. Anyway, we are here to talk about Elevate and this react flow. Dennis, can you share my screen instead of John's please? Thank you. All right, so for a lot of us Elevate is something that maybe we didn't know existed until maybe some of our clients were like hey, I'm using Elevate. How do I do something on it? Well we have a flow for you guys to start working with it and at least see the code and be able to build some child themes with it over the next couple of minutes here. My general plan of attack is that I am going to walk us through basically just the demo, how to fetch this down, how to start working with it locally, how to create a child theme if there's time left over. I will also try to demo just building like a quick module with it. However, I think that there is cause to maybe not have time for that, in which case we can always push it to something else. There's a later date also worth noting real quick that if there are questions as we bumble along, please, please, please feel free to ask them. I'm going to try my best to be watching the chat, but I also have Anton and Tune here to Help me kind of moderate. They're also going to be asking questions. So if things get confusing, if you need me to slow down, feel free to holla. Holla. With that being said, let's dive in right out of the gates. Elevate lives now inside of a public repo A couple notes on this repo. It's a mirror of our internal repo which means that we're not actually pushing updates to this directly. It's just going to be coming from our internal repo, which means that if you likely have feedback, you can go ahead and try to create an issue here or create pull requests. However, it's very likely that we won't see them putting that out there moving Forward. App HubSpot CMS Elevate Theme Public that's where this lives. To get this down, we're going to go ahead and code, grab the URL, hop into a terminal and we're just going to run a command, git clone and that repo. Voila, we have it. Let's go ahead with CD into there and list out what we got going on and we can go ahead and open it in your IDE of choice, which for me happens to be cursor. I'm going to bring this over here. We can see that it is existing inside of our theme are inside of our project. Now let's just go ahead and let's try to get this running right. So in order to do that I'm like John was saying earlier, I'm just going to go ahead and push it up to my portal and then we'll try to get the dev server running. So to do that I guess we're coming in this blank, I should say. I maybe have not built with like node projects before. I don't necessarily know what to do to get this project off the ground. We've got a nice readme file in here that should take us from zero to hopefully I know what I'm doing and get this running relatively quickly. This would be a really good thing to check out if we are a little bit more experienced. We probably know to look at our package JSON file to find all of the available scripts that we can start running here. We've got a nice yarn and NPM route depending on what you prefer. Feel free to choose your own adventure. I am going to go the yarn route here. I'm going to go yarn yarn, install all just to go ahead and install all of the dependencies. Like John was mentioning before, projects consist of two layers of dependencies. There's the project dependencies for working with it locally. Then there's the project dependencies for the actual react build itself. This command yarn yarn install all is going to make sure that all of those dependencies are installed in one file swoop. Awesome. We've got that installed. Now we're going to go ahead and upload it to our project or upload it to our portal. To do that, I'm just going to run yarn build upload. Now I can make this a little bit bigger so we can kind of see what's going on. Now we can see that our CSS mini files, which we'll go over in a little bit, have all bundled together and have been built. And then we're being asked a question. And that question is the project elevate public theme does not exist in your portal. Would you like to create it? And of course, the answer for that is yes, I would love to create that. Great. Now it's going to start to upload that project. While it's doing that, I do want to circle back and just touch base real quick on what some of these important files are. John kind of mentioned this earlier, but at the top level, at the root of our directory here, we do have this hsproject JSON file. This is really important. This is going to be the name of the project when it gets into HubSpot. It's not a name that marketers are going to see, but this is going to be the name of the project that you as a developer are interacting with. This name is entirely separate from the theme JSON name.

That's really the answer.

Yeah.

Quick question. Would it be possible to maybe zoom in in the sidebar a little bit? Because I think it's not that visible in YouTube. Thanks.

Is that better? Let's see. I'm going to go in and make the actual font size down just a little bit then. How's that good.

For me? For me? Yeah. Chad, what do you think?

It's not good. We can. We can update on the fly still. Here we go. We're going to keep trucking.

Awesome.

This is separate from the theme JSON file and is just an important name that we need to make sure that we're keeping track of. If I were to change this, I would get that same warning that I got or that same flag where it says this project does not exist in your portal. Do you want to upload it again? And I would say yes. That being said, if we jump into our source folder, this is the theme as we know it in Hubble land. A lot of this markup. A lot of this file structure should look pretty similar or pretty familiar. Again, the important file here is going to be the theme JSON file, right? And in here this is going to be the name that people see when they go to create a page. So that part I feel like is expected. So let's go ahead real quick, circle back to this and let's see. We're getting some, we're getting some errors because we're doing it live here. What's going on? Jumping all over the place. Raw assets already exist at the given path. Okay, well let's just see if it built. I think it. I think it may have. No, it didn't fail. Build build Problem building one. Well, that's what we get for doing this live. Let's try to run that again. Yard Build, build, upload. Well, this is a good point in time to I guess explain that there is error logging that does happen and it is generally helpful. So here it's just saying that we have a whole bunch of validation errors that these RAW assets already exist at the path that we're trying to upload it at. Which my guess is that this might actually fail again, I guess. Do we have any questions while we're waiting for this to build? So far, are we feeling good?

Yeah, I think we, we have one question that we could handle right now. I think it's also for John in the dev server. Do you think that live reloading, hot reloading is going to be something that is available?

Yeah. So we have HMR hot module reloading for our modules and things like that. The gap would be I guess on the Hubble template side viewing those because we should be having HMR on the viewing app view of the. We have to actually manually refresh for the fields update to happen, but the render on the right side will update anytime there's made changes. Same with the local version of your module. So both those work. The template being a Hubble template, there's a little different flow for how we. You can think of like the previous Hubble flow where you have to like run a watch command to then constantly be pushing those Hubble changes up. There's a little different flow that makes HMR a little tricky. But yes, that is on our radar to make all of that a little bit more snappy when you make updates and not require a hard refresh. And there's some future proof changes that we will be making to the entire CMS React project ecosystem that's maybe less dependent on Hubbles all the time. That might help with some of those things in the future. But as of now, you do have to do a hard refresh on the Hubble template specifically.

Cool.

These new features that we have available, building teams with React and projects, will that be available in all portals independent of the subscription type?

Yes, building with CMS React is available in all portals. There are some features like GraphQL that are tier specific. There's going to be some nuances there, but yes, you can build CMS React with the free portal.

Awesome.

Cool.

Sweet. Trying out a couple fixes here while we wait. I think what potentially the issue was. Yeah, what the issue was is that while I was prepping for this, I had created the same exact project name and then deleted it. I think there's some conflicting logic in the back end to make that happen. But anyway, we got it all built and it is working now. So let's go ahead and take a look at what this looks like inside of our portal. So we got a portal. We're going to go ahead and create a web page with it, get started. And here we're going to scroll down to oh, I got two now that's the issue. So what I'm going to do to just distinguish that is hop back into my theme and we're going to rename this B hug and we're gonna rebuild and re upload that. However, I can just take a guess at which one it is. And yeah, we can see that we've got all of our like theme files uploaded here. So we're looking at all of our templates. Then it works as expected once we're here, just like we're building a normal theme that is super cool coming back like John was mentioning, let's pretend that we've got this uploaded, which we do. And now we want to make some local edits. We're going to go ahead and we're going to open up our yarn, sorry, our dev server. So yarn, yarn start. We'll do that. Oops, I have to CB into the theme. Yarn, Yarn start. And then we are going to be just like John was doing, building and kind of compiling that initial dev server there. So while that's going on, let's go ahead and let's just take a little peek at kind of the overall structure of the elevate theme. So I'll close these guys out here. So elevate here Internally, a lot of us, most of us are using cursor as an id. So cursor comes if you're Unfamiliar with kind of AI baked into it. I'm not going to say what tools you should or should not be using. However, if you do end up leveraging cursor, you do get the benefits of getting some of our baked in experimental cursor rules that we've been working with out of the gates. I won't have time today to demo what these rules are. However, they do exist here at a high level. The rules that we have all surround building REACT modules. We've got a high level rule for just scaffolding a generic module, in which case you can take an image, say you've got a comp of a module you want to build, you can take a picture of that, a screenshot, add it as context, give it some details as to what features you might want to have in it, and then it will scaffold out for you. Just a bare bones module. Then we've got a rule that says generate some fields so you can give it some more instructions and it'll compile the fields for you based on like what we kind of have set of standards inside of our elevate theme. And then we've got a generic like, go ahead and just like flesh out this module. It is AI, so it does require some like user balancing, but it does like increase or decrease the amount of time that it takes you to like build a module really, really well or really efficiently. So it's pretty cool to leverage these rules. I do have a demo Fish mode that we have here just so you can see how it runs. The way that you would access those rules is just by doing cursor and then you specify the rule that you want in this case Fish mode, you give it something to do. I'm going to say what is one plus one? And then it's going to tell you that Fish mode is now active. Glub glub. The answer to your question is two Club Glove. So fish mode is now officially HubSpot sponsored. You're welcome. Moving on, we've got a build directory. This build directory has just got some basic utilities for how we're handling css. And then like I was mentioning before, this source directory is kind of the bulk and the meat of what our theme actually is. So again, most of this could look pretty darn familiar if we built themes on HubSpot in the past. However, some notable differences are going to arise inside of this Assets directory. This is where we're housing all of our css. It's inside of this HS and then CSS directory here. If you're building your own project, you can choose to structure it how you want. Within reason, we're choosing to heavily leverage some post CSS processing tools. That means that if you're coming to edit CSS files, you're probably going to be doing it here. Then when we run that HS or when we run that yarn build command, this is going to bundle all of our CSS files that we have here, which are really small, into a singular main CSS file. Those files are going to live inside of this disk directory. This is going to come in handy a little bit later when we try to scaffold ourselves a child theme. Anytime that we're referencing a CSS file in a template, it's going to be coming from this dist directory. That is really important to note. The other notable difference is inside of this components directory, modules as we think of them in Hubble land, exist inside of components and then modules. The modules directory here, right? So accordion, anchor, button, card, etc, etc, all of these are traditional HubSpot modules just built in a React way. We then might be asking ourselves what the heck is the difference between a component and a module? To some degree, they're very, very similar. Components I would like us to think are like atomic pieces of code or macros if we're coming from the Hubble land, that are just far more flexible than how macros actually exist inside of Hubble. Let's say, for example, I've got a button module and I've got a card that uses a button as well. I ideally don't want to repeat that same button markup inside of both places, inside of both modules. So what I can do is I can create a atomic button component and then slap that in both of those modules, which may not seem like a huge boon to production here. However, in a month, when I need to come in and make an update to all of the buttons across my theme, I know that I can come to a singular place to make that edit. So that in and of itself is like a huge, huge boom. The other place where this really comes in handy is inside of this field library component here that are field library directory. When we're building, if we take a look at these modules, let's just pick our button module. For example, if we take a look at our fields file, we'll notice that this is also written in React, right? And we've basically just got a whole bunch of different button components or field groups, field components that we are reusing throughout our theme to create, to keep the marketers experience very Consistent no matter what module they're editing. So in our case, if a module has a button on it and it is editable, all of the fields are always the same and we're making that happen by consuming these field library components here. So definitely recommend if you are building your own theme from scratch that you, I mean you don't have to, but inheriting and kind of using that field library structure is going to be huge. Big time saver. Cool. So let's come back here. We've got our dev server running. Let's go ahead and open up our dev server real quick. Again, we can see we've got a lot of what John was talking about before. We've got a whole bunch of modules, we've got all of our modules showing up here, apps, local versions, then we can come in and view our templates and whatnot. John already covered the editing process and demoed that. I'm going to breeze through that section of my talk a little bit. But before I move on, does anyone have any questions? Anton Tune have I been missing anything big?

I mean it all looks great and I think Martin's question is very legit. So if you're a marketer and you're using Elevate or your own Elevate clone, I would say will the AI builder always use elevate or can it be changed?

So to say the AI builder, are we referring to like these cursor AI prompts or are we referring to like AI code generation within or AI web page generation inside of HubSpot?

I assume he's talking about the page generation itself.

No, Content Hub. So yeah, page generation.

Yeah, yeah. I personally am not super familiar with all of like how that product is set up. I think right now it might be linked to, I think it might be behind a beta. I could be wrong on that, but I'm just going to go ahead and say that we're going to circle back to that question and answer it after the talk when I can actually respond to it intelligently. So good question. We'll get back to you quick, quick other question.

BJ yeah, in this case from Nick, he's asking if we can create the module fields in the Design Manager similar like we do for Hubble based websites and modules and then leverage the HS fetch CLI command to pull the fields towards the project.

Yeah, so this is a really good question. If you're building with elevate, you do have to go through the elevate kind of flow or if you're building with a react project you do have to go through the project flow, which is what we're kind of outlining here. However, if you're working with a child theme, and this is a really good segue, you can build a child theme of elevate inside of Design Manager. However, you are going to be. If you do that, you're going to be stuck to just doing Hubble modules at that point, which I think is really great for some of us, and some of us not so great. So that being said, let's go ahead and let's segue into just a couple quick examples of how to build a child theme. So let's say that we don't want to do anything with react, we don't want to mess with this flow at all. The way that we would go about doing this, building a child theme of Elevate inside of Design Manager would be like this. I've already got one set up here, but walking from scratch. We're going to head into Design Manager file new theme. I'm going to choose a blank theme as a starting point and just name it whatever you want. D hug child theme. Awesome. From here really just have two steps, right? Step number one is going to be adding the child theme extents so extends and then at HubSpot, Elevate and then just make sure that it's labeled something clear that you'll be able to see. So DHUG child theme. I think that's clear enough. The second step is that you'll need to copy over the fields JSON file. This is blank to start with. So we're going to come into Elevate here what we had pulled down. Or if you want, you can just grab it from the git repo, go to the root level fields JSON and we're just going to copy all of that and we're going to paste it in here. Publish that. Now we technically have a child theme created. If we go back to a page editor, go ahead and walk through that flow again to make sure that it worked. Going to create a new page DHUG filed theme. Design Manager. We're going to change theme and we're looking for D hug child theme right there. So that's the new one that we created. Oops, oops. What happened here? Extends add hub spot elevate D hug child theme. What am I missing? What am I missing? Brains field files in there. Child theme is in there. That's a theme. D hug child theme ad hip spot elevate templates show up.

The chat is mentioning that you have to Publish.

Yeah, I think I just did. Let's go back. Okay, well, maybe that was it. Maybe I didn't publish it. Nice job, folks. Here is all of our templates. Again, this is working publish file. I'm not used to working in dm. Yeah, we've got our template set up now. Let's go one step further. Let's say we want to override one of these files. We're going to hop back into Design Manager and let's say that we've got the. I don't know, let's pick one, the Rich text module. Here we want to override a rich text module. This works the exact same way that it does when you're overriding standard Hubble modules. The kicker, excuse me, is that the file paths have to be exactly the same. What we need to do is create a new folder in here. We're going to name this components and then within the components, right? We need to grab our modules directory. So we're going to create another directory modules and then within here we're going to create our actual modules, right? So I'm going to create a new file and then we're going to go module and we'll say site pages and we're going to name it same thing that it's named inside of our theme, which is Rich Text. Now this is actually something I want to note that we'll notice that inside of our theme, inside of our modules, we've got Rich. Rich text, right? This is Pascal case, right. However, if we open it and go into our index file, scroll down to the bottom, we will notice that we've got this default module config. When you're building your own modules, you don't need to add this. However, we've added it for some internal use and it also tells you what it's actually named inside of HubSpot. So this is the name that you have to reference, right? Rich text. So as we can see here, we've named it Rich Text. We will create that. Now we've got a module and I will just put a H1 inside of here and say this is overrated. We will make sure that we publish that. All right? Only truth. We come back, give us a refresh. This is overridden. Now, any place where we were referencing a Rich text module before, we are now referencing a Hubble Rich Text module within Elevate. So in general, I think most of us can probably fly from there. Pj yeah.

Question from Chad. And you might, might be answering this further in your demo, but do we have React support in child teams or can we only create child streams through the Design Manager?

Yep, that's where we're headed next. We've got this child theme kind of built out in Design Manager. If we want to go ahead and build a child theme in React, we've got a couple of options. Option number one would be that I can pull down the elevate theme. I can then, excuse me, blast away all of my, like all of the directories inside of the source folder here. So I'm going to blast away templates, sections, images, helpers, components, assets, basically everything. The main things that I want to keep in here are the fields that JSON the theme JSON, right? And then probably these package files. Other than that, we can blast everything away. And the rest of the flow is exactly the same as to what we just did. So we need to hop inside of our theme JSON file. We would need to add extends, and then that's it at HubSpot, elevate stop. And then we would just upload this again and that would be a new child theme based off of our Elevate flow. The other flow that I do want to also highlight is what John was doing earlier. This is a flow that I would likely recommend. It would start you from a clean slate and allow you to utilize whatever tools that you want to use. In this case, we'll CD out of here. That would be running that NPX at HubSpot/Create CMS theme at latest. Right. And John kind of walked through everything that it was asking us here. But this is just going to install, like John was saying, a blank theme with one module inside of our whatever directory here. So see, what is the name of your theme? We will say Dhug Tile Theme Local. Do you want to use TypeScript? I do. We'll create it inside of here. Proceed, please. Yeah. So, any other questions?

Yeah, so I think one question that is popping up. Do we also have the option to see React code and Design Manager, or do we need to use a different place to view the code inside HubSpot?

Yeah, good question. So currently the project's flow is completely separate from Design Manager, right? So if you want to view code, you. You do have a couple of options, right? Option number one, when you go and build an upload, you will see that there is a, gosh, all the big text makes this super, super long. There is a link that will kick you over here and here you can look at your project. Right. So this is what it was named in the project file. There and then we can look at our actual builds. So here we can see all of our code. That's an image. Not helpful. Components block, component index. You can't edit these here it is just read only. But yeah, you can view all of your code from that link there. But the main, main source of truth that you're going to be working with is likely going to be a git repository of your own. Or pulling these projects down and working with them locally. Makes sense hopefully.

Definitely.

Cool. Yeah. Into local. Here we've got a new theme. Let's open that up. All right. So once we have this open.

The.

Same kind of flow as we were following before. Right. We're going to want to. It's already named what we want it to be named. We're going to come into the theme that is also named appropriately. The main thing we have to do here is add that extends again extends at HubSpot, Elevate and then we also again have to copy our fields JSON file inside there. Now we can install it. Once we have it installed we can go ahead and run our build command. Actually don't. Off the top of my head, if it is build command on this one, it's deploy yarn deploy. So that's going to kick it up the HubSpot. It's asking again, do you want to create it inside of your portal? I say yes, of course, and saying we're missing a label. I guess the quick fix for this is I'm just going to copy everything inside of my theme. JSON here, paste that over here re add that extensions. That helps my elevate. Oh, it resonated.

Why are you doing this? Quick question. Would it be an option or a migration plan to convert existing Hubble based teams into React based teams?

That is a good question. I am unfamiliar if there is a plan. John might have some additional context on that. But yeah, I'm not sure at this point.

Yeah, this has come up. Like what. What easier pathways can we make for people migrating? There's not a current avenue for us to make this happen. We're attempting to make the migration, the manual migration a little bit smoother by having these being able to have a project theme that has Hubble and React coexisting so you can pull over all your Hubble code into a React project even though there's no React in it yet and start slowly building React modules to replace your Hubble modules. But as for some automatic migration tool, there's nothing in the works right now to map those Hubble modules. Into React modules.

Cool.

The wrong thing there. I did a sturdy and renamed it that.

Oh, what is an interesting question. So I think people are wondering because we are now moving to React based websites and teams right inside HubSpot, what will that mean for the Design Manager in Hubble? Is that something that you know already?

Yeah, so I mean Design Manager Hubble as far as I, as far as I know isn't going anywhere. I think we, I think it would be very hard to make it go anywhere frankly because it's such a bedrock of like HubSpot development right now. So I don't think there are any plans of it leaving us anytime soon. Yeah, yeah.

The only, the only thing I'd add to that is just the Design Manager is still widely used by non devs that don't have a local setup for Hubble specific things. So we're not planning to necessarily eliminate that anytime soon or there's no immediate plans to do anything like that. But since React and Hubble behave differently, the Design Manager doesn't support React code within it to do that editing because there is this build step that's required to take that React to transpile it down to just normal HTML, CSS and JavaScript stuff. So hopefully that helps clear it up. There's just that they're just different paradigms that exist which is why we can't use things in use React in the Design Manager. But the Hubble pathways are still in existence.

Yeah, makes sense.

All right. D Hug Child Theme Local well.

D.

Hug Child theme this is the problem when we do this so many times in one place I start naming them all the same. Here, let me back out of this and let's just recreate a new page Feed Hug theme local.

We got a question from LinkedIn. So will the theme that you built in React or locally use the branding kit options?

Can you ask that again? Sorry, yeah.

Like the fields of our React theme, will they utilize all the brand kit settings that you set in the HubSpot portal? Because in the current fields, Jason, you can link them I would say.

Yeah. So in elevate we've done, I mean we've purposely tried to build it so that we're like leveraging brand settings as much as we can and have those settings kind of flow through the theme where it makes the most sense. And then we've also done a really good job I feel of trying to connect theme settings kind of globally throughout the modules. So if you can set something, if you have a setting that exists at the theme level, you can't override it at the module level, at least in terms of how Elevate is structured. And that is done specifically to make sure that, you know, marketers have a harder time of kind of making things look bad. And they're always kind of consistently using a singular design approach. Yeah. Cool. I think in the essence of time here, I think we're going to move on to just like general Q and A. As I see that, we're like a little bit over and I don't want to eat up all of our space here.

Yeah. All right, I'll try to go through this quickly and I'm going to just.

Go ahead and remove your screen for now and have a better setup than that. Cool. All right.

I will try not to be redundant because I think some of these were asked, but I want to get to Andre, who asked a while back, will Tailwind work with a setup? They had a follow up, I think. How much control do we have over the CSS processing, for example? So thoughts on that?

Yeah, Tailwind, I think, should work fine. I don't think that I've experimented with it per se, but if you can add anything to a vite config, that's what this pipeline is built off of. I think any approach to CSS that you want to take, you can definitely handle. I think a lot of the REACT docs have examples on how to do it with CSS modules. Elevate is using styled components. Yeah. So I don't see a reason why Tailwind off the top of my head wouldn't work. Cool.

Moving on. Let's see. I got that out of the way. Dimitri had a couple questions. One was going to be on REACT support and child themes. Yes. No, when you make a child theme, you have react. Yes.

Yep. Beautiful.

Another question, and this one goes to John, I believe is a question on React 19 support.

Are there any plans? Yeah, totally. Yeah. We have plans to enable React 19 support. We do not have it today, but it's definitely on our roadmap to get that going.

While I got you, John, Mark asks, other than is Creed the best band in the world, any plans to eventually absorb create CMS themes into a general HS cli?

There are talks about how we can unify some of those experiences of now we're going to keep this as a separate package since the CLI does a lot of other things and there's not a clear pathway to make that happen for us. So we wanted to hurry up and get some stuff out for the developers to have a Better way to bootstrap a project. But totally we work closely with that team internally. So we're definitely trying to make sure that we are creating more commands in the HS space when necessary and then when can't we escape hatch out of that into building our own things?

Let's see, getting rid of some stuff here, John. John Fuller asks for creating our own React theme. Do we need that in the model? Open it up for child themes.

Specifically, he was referencing the part where you had a text underscore or support the module when creating the Hubble module in your child team. The config.

All right. Okay. So this is related to module. No. Oh, okay. Do you need that default module config? Is that. That's a question? No, no, you do not need that. That's really for internal use, but it is helping everyone else kind of see that like internally hubs like those modules are stored at a slightly different name than what it is up top or what it is at the directory level.

All right. Jared asked a more philosophical question, but is this considered by Hustle what the future will be? And like the old CMS died and was replaced by themes. Will this replace themes? I'm not quite sure if that's actually. I think we need some definitions perhaps because we sell themes. Themes has not gone anywhere.

Correct.

I think Jared refers to the templates, to the very old templates like vast. As we all know that themes or growth replaced vast. And now I would say elevate will replace growth and yeah, so yeah, go, go.

Sorry.

Yeah. Bj, I. If there's probably one question of like, is React replacing Hubble? And like the short answer is like, no, it's not replacing it. And yes, it is replacing it.

Right.

So no, from the standpoint of like, Hubble's not going away, but React provides so, so many benefits that I highly recommend like everyone start playing with it because site speed increases, you get type safety if you want it. And like TypeScript just comes with a bunch of other benefits that are hard to kind of list out in a short amount of time. But honestly just spending, you know, a couple. You don't have to adopt it right now, but spending a couple of months, you know, an hour a week, just like getting familiar with React, starting to play with it. Like, you'll start to see that I think once you get play with it there really isn't going back. Like it just, it makes your life so much easier just having everything kind of be unified and shared and all built in. JavaScript if you want it so it's really just modernizing our stack to like, honestly, what the standards have been for a long time.

Cool. And to add a little bit to that. The, the, the, the question mentioned themes like the, the building block of a theme, that entity is not going away. We are just now incorporating React into that themes entity. So you can now have Hubble and React Mix. Hub templates as of today are still Hubble files and you're just importing your React modules into those files or drag and dropping them. From a marker's perspective, that is not going away. That is like a core building block on the cms. Elevate itself is a evolution of a default theme that you can use. Say you're a marketer that wants to just pull that in and you're not a developer, you get a good base point or you're extending it as a child theme. So I think BJ touched on some great points, but it's also probably worth knowing that the vast growth Elevate theme is not a change in the entity type. It's just a change in the default theme that we're providing you from a HubSpot perspective.

Yeah, so that kind of dovetails into this one here. Can I mix new templates into my existing React project that is still using Hubble templates?

And as well, can I mix in new templates into my existing React project that are still Hubble? Yeah, so you can. All templates are Hubble templates as it stands today. So yes, you can mix that. And you can, you can take your Hubble theme, your only Hubble theme, and put that into a project and deploy that through our project system. And that still works as well. You don't have to have a React to do that. It's a little unnecessary, I guess, to do that because you're not a build step for Hubble. But then you get atomic deploy. So instead of HS watching or HS uploading individual files all the time, sometimes breakages happen and it's hard to find where that broke. If you're iterating quickly and pushing up lots of changes to all your Hubble files, having these atomic deploys in a Hubble Only world can be beneficial because you have this. Like I've got Deploy A and Deploy B. I can go back to Deploy B if something breaks. You have these flows that are more typical development flows that are enabled with projects. So we encourage you to use React, but you can use the project system in a different way as well to keep your Hubble world going and then slowly migrate onto Using React Question regarding deployment.

I know that the current CLI allows you to reference an environment file to determine where your code should be deployed to. Right? Is that something that will be available for projects as well?

I believe we have GitHub Action Support to then deploy your code to a GitHub repo and then you don't have to auto deploy. You can turn that off in the project system. If you wanted to have some review process, you could still do the build, make sure everything builds and then you can choose when and what build to deploy at that point. So there is some flexibility about where I mean it always ends up in the portal. Not as of today. There are some. That's kind of a sticky problem. So it's on our radar and something that we want to enable support but as of today we cannot publish themes that have React in them right now.

Moving on and thanks for getting this back to me. No, Jason has it here. It was asked by someone else. This is not a question from Jason but he tagged it for me. Thank you. React modules theme support for multiple language or translations do we support this?

Yeah, yeah. Just having everything kind of be unified and shared and all built in JavaScript if you want it. So it's really just modernizing our stack to like honestly what the standards have been for a long time. Cool.

And to add a little bit to that. The, the, the, the question mentioned themes like the, the building block of a theme. That entity is not going away. We are just now incorporating React into that themes entity. So you can now have Hubble and React Mix Hub templates as of today are still Hubble files and you're just importing your React modules into those files or drag and dropping them from a Markers perspective. So that is not going away. That is like a core building block on the cms. Elevate itself is a evolution of a default theme that you can use. Say you're a marketer that wants to just pull that in that you're not a developer, you get a good base point or you're extending it as a child theme. So I think BJ touched on some great points, but it's also probably worth knowing that the vast growth elevate theme is not a change in the entity type. It's just a change in the default theme that we're providing you from a HubSpot perspective.

Yeah. So that kind of dovetails into this one here. Can I mix new templates into my existing React project that is still using Hubble templates as well?

Can I mix in new Templates into my existing React project that are still Hubble. Yeah. So you can. All templates are Hubble templates as it stands today. So yes, you can mix that and you can take your Hubble theme, your only Hubble theme, and put that into a project and deploy that through our project system. And that still works as well. You don't have to have a React to do that. It's a little unnecessary I guess to do that because there's not a build step for Hubble. But then you get atomic deploy. So instead of HS watching and or HS uploading individual files all the time, sometimes breakages happen and it's hard to find where that broke. If you're iterating quickly and pushing up lots of changes to all your Hubble files. Having these atomic deploys in a Hubble Only world can be beneficial because you have this like I've got Deploy A and deploy B. I can go back to Deploy B if something breaks. You have these flows that are more typical development flows that are enabled with project. We encourage you to use React, but you can use the project system in a different way as well to keep your Hubble world going and then slowly migrate onto using React.

Question regarding deployment. I know that the current CLI allows you to reference an environment file to determine where your code should be deployed to. Is that something that will be available for projects as well?

I believe we have GitHub Action Support to then deploy your code to a GitHub repo and then you don't have to auto deploy. You can turn that off in the project system. If you wanted to have some review process, you could still do the build, make sure everything builds and then you can choose when and what build to deploy at that point. So there is some flexibility about where. I mean it always ends up in the portal, but you can then have this GitHub intermediary or whatever your repository tool is media to then get that into projects once a PR is merged and stuff like that.

Awesome.

Does anyone know the answer? Can we publish REACT based themes onto the marketplace?

Not as of today. That's kind of a sticky problem. So it's on our radar and something that we want to enable support but as of today we cannot publish themes that have React in them right now.

Moving on and thanks for getting this back to me. No, Jason has it here. It was asked by someone else. This is not a question from Jason, but he tagged it for me. Thank you. React modules Theme support for multiple language or translations do we support this?

Yeah, basically anything you get in a normal module that you get in the REACT module. You're still leveraging locales directory with messages, JSON and stuff like that. Like that. And that flow is kind of already built into what we have pushed up to the public repo. So you'll be able to see that like there is a locales directory and they're everywhere. It is worth noting that, you know, if you add a bunch of languages, it does, you know, it has to upload all of that stuff. So when you go to build and upload it, you know, it takes a little bit longer to build. But yeah, all of that stuff is still available to you. Yeah, perfect.

I think I'm going to close it out there. We're a little over time. There's been a lot of really good questions and I'm sure I missed several. I am putting in the chat a link to our CMS REACT channel in the dev developer Slack. Ask questions there. There's a lot of people, John, bj, both are there looking at that all the time. We take a lot of suggestions from it and we want you all to be happy. So ask the questions. We will probably be doing another follow up d hug session on this, going more into detail with BJ if he so wants to do it with us. And of course John's always invited back because he has some amazing things. So yeah, from all of us at the developer hug, thank you so much for being here.

Yeah, thank you.