Elements Developer Guidelines

I’ve been going through the current Elements Manual in preparation for beginning my journey to create custom components, and was wondering if there were (or will be) any guidelines on developing custom components (for personal use, or for sale)?

I’m most interested in how to make my custom component feel like a natural and intuitive extension to Elements, and not some weird monstrosity that is an enigma unto itself.

So far, I’ve gleamed the following ‘guidelines’:

  1. Embrace Tailwind, it underpins all stying in Elements.
  2. There is currently no default JavaScript library that ships by default in Elements, although both vanilla JS and Alpine.js are used in the built-in components. This is where it would be nice if there was a default lib within Elements that developers could use if they don’t wish to include their own (which can add a lot of overhead).
  3. Include your own JavaScript libraries (and other dependencies) in your component(s). It’s currently unclear how this works given the current custom elements UI. Also, will Elements automatically optimize/minify all dependencies on publish, or should custom elements ship pre-optimized?
  4. Component properties/UI and best practices in terms of property naming, grouping, UI controls used, etc appears to be open to interpretation currently. This seems where some guidelines could really help in order to ensure some continuity in user experience between components in Elements. ie. when to use UPPERCASE, lowercase, Title Case, etc for property names, colour selection via theme colour sliders, not drop-downs, etc.
  5. Being able to edit and manage components externally during development (ie. using Nova, Code, etc) using the defined bundle structure and package and deploy directly to Elements for testing would be ideal, but there doesn’t currently seem to be a way to do that within Elements. I’m assuming this is in progress?
2 Likes

This one I worry about if you depend on this and something gets updated in Elements your going have to go back to your custom components and check nothing breaks. Same reason I dont use online CDNs.

1 Like

The same could be said of Tailwind itself, or any extensions to Tailwind that rely on a specific version.

1 Like

Yes, another GenAI post! :stuck_out_tongue_winking_eye:

There are a lot of Tailwind specific custom GPTs on the GPT store. Here is the link to a popular one…

Tailwind CSS By Widenex

1 Like

previously asked if a video demonstrating a conversion of a custom component into a reusable component, not just hello world example, I am poor at reading explanations, once see it visually I get there quicker, plus I am still learning. re external editing a pop out editor with a bit more auto complete would be great a bit like tailwind playground

We don’t think shipping a default library (that is always included on the page) is a good idea.

A developer will have the ability to include javascript libraries on the page once their component(s) are added - this isn’t quite ready and so more info on will follow later.

We are also considering having some popular javascript libraries available in the app so that a component can require its inclusion, but this would be opt-in.

You will be able to include your own javascript with components.

We have plans to improve optimisation and magnification of assets, but again, we’re not quite there yet.

I’m sounding like a broken record here: we don’t have this ready yet. It’s coming though!

Correct, creating packaged/shippable Components is not currently available. We obviously have this setup internally so we can ship the Components you see in the app - and I have to say (tease) that it’s an absolute joy to build Components :smiley:

This is… you guessed it: coming in the future!

2 Likes