In this chat, Ben and I dive into building custom components in RapidWeaver Elements, exploring how properties, resources, drop zones, and hooks all fit together.
If you’ve not tried creating custom components or you’re just getting started, this one’s for you.
We also very briefly discuss the upcoming Store launch and how developers will soon be able to share and sell their own creations
There’s also about six minutes of moustache talk at the start so feel free to skip ahead using the YouTube chapters if chit-chat’s not your thing
I hope this doesn’t come across as too critical, I really think Elements is great, and it’s amazing how much users can create right out of the box.
That said, I wanted to share some thoughts from a third-party perspective. I think there’s a bit of an assumption that third parties can easily add “a couple of simple controls,” but in reality, it’s far more complex to build polished components without access to the same build system and infrastructure that you have.
For example, take your recent Audio component, that’s not something third parties can realistically build. It could be simplified by removing things like transforms, but it still relies on background and other groups that require thousands of lines of custom JavaScript in hooks.js.
Colour handling is big one, almost every component needs colour in some form, whether it’s text or background. So third parties are left with two choices: simplify do a static colour, or create a proper colour group like yours, which again involves many hundreds of lines of custom javascript.
Reusable helpers sound great in theory, but as far as I can tell, there’s no way to include external helper files in hooks.js.
I don’t expect an immediate solution, but I wanted to flag that the tone in episode 2 suggested it’s “good enough” for third parties to build nice things. In reality, it’s still very difficult without more accessible tools or structures.
Elements really is an impressive system, I just think a bit more focus on how third parties can realistically create “nice things” would make it even stronger.
Thanks for writing this, it hits the nail on the head!
I have been trying to add support for the standard properties to my custom components, only to find that a lot is going on that is not clearly articulated. Some of the things sound simple on the surface, but once you dive in, you run into problems. Some of this is due to a lack of solid working examples or documentation.
A simple example: add a background color property that matches the one used in the core components. It utilizes a segmented control to select from different types of background colors. One of these is a NONE segment, which, when selected, is intended to remove all background color information; however, there is no information on what that entails.
The examples @dan recently added to Git were incredibly useful, but without the associated hooks.js file, that are essentially useless if you are trying to mimic the core components.
I would really like to see the associated hooks file for the Container component. Please!
This is a common request from other developers. I’m working on it, and now I’m wondering if it’s possible to dedicate time to developing new things rather than trying to replicate the current structure of standard components.
It’s not necessary to replicate everything; some things, in my opinion, aren’t always necessary, but others are very useful.
I agree 100%, but there are some commonly used properties, such as colors, where it is helpful to replicate what is done in the core components.
However, I must be honest, I’m starting to question how much time I spend trying to replicate these things, as opposed to simply focusing on what I need to do.
But I’m always driven by what the user experience will be like if I don’t follow the guidelines established by the core components.
These are two different things, and we can make a huge educational contribution to users.
Current components offer many options, but a specific component should only offer a limited range of options to prevent users from making mistakes.
This aspect has been one of the cornerstones of RW’s success over the years, both in themes and stacks. The developer knows exactly which ranges to enable and in which situations, and this greatly helps the end user.
In any case, the users will decide, once they understand how external developers work and what tools they have at their disposal. The important thing is to work hard and offer a quality product!
Thanks for the feedback @Doobox I’ll try to address all the issues you brought up below.
The controls in the Core Components took me many, many hours to create, so we definitely don’t assume it would be easy for a third-party to replicate them.
That said, it is absolutely possible if you’re determined to do it. As we’ve mentioned before, our components use the exact same APIs available to third-party developers. There’s no special access or hidden functionality.
So yes, it’s a lot of work to build controls that match the Core Components, but it’s 100% doable
You could certainly rebuild that component if you wanted to, but I’d take a step back and ask whether it’s always worth replicating the Core Component controls.
The Core Components are meant to be the flexible, low-level building blocks. Something users can combine together to create templates. Looking ahead, and now that the store will soon be available for third-parties, I don’t think every component needs to offer the same range of options as the Core Components.
While the Core Components provide a lot of flexibility, they also come with a steeper learning curve. Not every component needs the full set of controls in the core components, sometimes less really is more.
Components designed for a specific use-case, with a simpler and more focused set of controls, will likely be more approachable (and popular!) on the store. That’d be my guess
I totally see your point! Creating complex background controls like in the Core Components takes time and effort. I do think there’s real value in offering components with a simpler, more focused set of options as they can often be quicker to use and easier for users to understand.
So while the advanced controls are great for flexibility, my thinking is that many users will enjoy components that offer “easy-to-use” controls just as much.
I completely understand where you’re coming from, and I really appreciate you raising these points. We absolutely want to make it easier for third-party developers to build for Elements, especially when it comes to component properties.
I want to point out that the JavaScript we use in the core components’ hooks.js files is quite closely tied to Tailwind. That’s something we’re very aware of, and we’d need to think carefully about before sharing the JS we currently ship.
We think it’s fine for individual components to rely on a specific framework, but we don’t want Elements itself to become fully dependent on one framework or version. If we were to introduce an “official” build system for components, we’d need to make sure it keeps third-party components framework-agnostic and future-proof.
Hopefully that gives a clearer picture of our current thinking! Really appreciate you taking the time to share this feedback, it helps a lot. Let me know what you think, we’re genuinely trying to make Elements the best, most enjoyable website builder out there
Maybe just me, but I’m not as motivated to create components with dumbed down controls, to avoid large javascript loads in hooks.js
I can do this stuff, it’s just such a lot of work. When I get I little inspirational idea, for something super simple like “Type on text” for example, my mind immediately thinks, Oh, General group, Color Group, Filters, etc etc.. And the motivation falls away. I’m sure Iv’e made that point clear.
I do realise it’s going to be difficult to do much in terms of reducing the Javascript load in hooks for component groups like eg: Color, and Background at the moment.
I did have one thought that may make life a hell of a lot easier for third parties and yourselves.
If you can find a way that the enable key when disabled will stop the expected value being returned, and instead return an empty string if disabled, then the js in hooks would be a breeze. No more need to test all the possible states of the group in js.
First developer to create a Markdown component has my money.
How does that component work?
Drag the component in and open the bottom inspector. Paste Markdown in the bottom Inspector and have it displayed WYSIWYG in the main view. Bonus points for working a bit like Typography, where selecting text in the WYSIWYG view allows change of text style in the right side Inspector (why do we have two things named inspector?). Super Bonus points for embedded images (can come from the Markdown pointer).
This is something I dream about every day. When the Elements beta first started there was a developer workin on this but I have not seen anything from him in a long time.
I wish to have an image and text box side by side.
I have used the 2 column insert, and also the 2 column left.
With either one the 2 are never side by side, but one is above the other.
I explained this to the forum, but people simply tell me to use the 2 column left, which does not work.
Any solution?
I’ve added the project underneath the video above so you can have a play around with the project.
I’ll try to address all the issues you brought up below.
