Pre-release video (will release later today).
You will have to handle the hooks file yourselves, but for now this is the fastest way to get the core groups UI.
Just need to create an icon, at a loss what represents this app
Might just have to go with something generic like a flower or something
Please please backup your properties.json file somewhere before experimenting, there may be bugs. The properties.json file is the only file it will amend.
Shipped with Sparkle updater, Component Props > Check for Updates.
You need SFSymbols app from Apple, All the icons are SFSymbols.
If you’re trying to match an icon, screenshot it and ask chat jippety “Which SF symbol is this?” Its good at identifying.
Yes, that is what I’m using, but I want to try and use the exact same icons that RM are using, which is why these samples are handy. I had asked some time back for them to provide a list of the icons they use.
I’ll have to see how ChatGPT does at identifying them, had not thought of trying that yet.
So the plan going forward to aid in processing the core groups output through your hooks.js file.
I will add a small javascript payload to each of core group items in the right hand inspector.
On right click you will get the option to “Copy Javascript” which will copy to your clipboard.
An example might look like this for Tag in the general group, ready to paste into your hooks.js…
If you’re using the controls built for the Core Components, then yes there is quite a bit of javascript logic running behind the scenes to make those controls work
We spent a lot of time designing the controls to be as intuitive and user-friendly as possible, which meant moving most of the complexity out of the UI and into the hooks.js files. The controls may look simple, but behind the scenes there’s a lot of logic ensuring each one maps correctly to the right Tailwind classes, and that those classes are applied properly. This approach also ensures Elements doesn’t force you (or us) into any single framework or version.
If you’d like to recreate our controls in your own components, you’ll need to implement some of that javascript logic yourself to handle things like state, logic, and class formatting, just as you’re doing in your example above.
One tip is to use the format property as much as possible. It allows Elements to handle some of the heavy lifting for you, including responsive prefixes. For example, a colour control can automatically output a class string such as: text-red-500 md:text-blue-500 lg:text-green-500
Some of the more advanced controls, such as those in the Background group, require even more logic to work correctly, meaning your hooks.js file will likely grow quite a bit. My advice is to structure it cleanly, and remember that it’s a standard javascript file, so you can add helper methods and organise it however you like, as long as it includes: exports.transformHook = transformHook;
If you have any other specific questions, or need help or advice on doing something in a component, just let me know
Yes, it all became apparent just how much logic mapping out a (on the face of it) simple control in the hooks file is required.
Most of the components I have developed would benefit from the inclusion of at least some of the core groups, and I expect that would be the case for all third party components.
I can map them out and make them re-usable. Just hadn’t foresaw the amount of js this was going to require.
I do hope in the future elements api will find a way (in layman’s terms) to ask for any core group, and have the macro for for the result of that call documented in the api. That seems like it would make things more approachable for third parties.
I’m working on it too, and I’ve realized there’s a lot of work to be done. Users will probably ask for it when they can compare our work with native components.
In any case, replication isn’t always necessary, but maintaining certain options is important to make the component familiar to the user
There is only one possible state, so you don’t need to worry about state.
you could just use {{cssClasses}} and {{globalID}} directly.
Mostly the issue comes when there are multiple possible states that the group can be in, like when there are options via select controls. Then you need to map the state in hooks to your own processed macro {{processedMacro}}
if you look at the colour group, there are 6 main states
@Doobox Thanks for clarifying that, Gary. That is essentially the approach I have taken, where simple things don’t go through the hooks file.
It is incredible, though, how complex the whole property process can become if you are trying to do it correctly. I’m finding that to make a component viable for the average user, you have to be very strict about matching the core components.
Which is where your tool will be invaluable and a huge timesaver.
But regardless that you can use these directly without processing. Even things like this can benefit from processing through hooks. in this example you could process in case the user entered junk, and not valid id and or classes. It’s endless what you can do via processing through hooks.
You might for example have in input where the user enters an email address. well while you could use that directly, it would benefit from email address validation via hooks.