Yeah, Iāve been doing something similar, but Iāll definitely be switching. Among other things, the built-in solution is simpler to use and lighter weight (from a DOM element perspective). I still have other, more sophisticated, āfunctional componentsā which are built using REās and properties; so Iām really glad to see this common UI element updated and enhanced.
@nick.carroll This feature is really good and thankfully, seems to have been shipped without any signfigant bugs. Thanks also for giving us a heads up before the feature was shipped.
I like most of the future feature upgrades (more comments below) but more important than any of those, and the only apparent regression of the new icon feature is the inability to search for a icon across ALL types of an icon library. In the example below, it shouldnāt require five(!) searches to see all folder icons. There should be an option to leave the icon library subtype dropdown blank, and when empty, search results should show all matching results within the library.
āā Can each one be on the ideaboard individually so Bubble can build the ones that its power users want most?
āā For these 2, there should be an ability to set the icon library in a style for both icons and buttons. This will eliminate the need for an app wide default icon library (and the additional fields it entails).
Also, once the button type can be set in the style, it would make sense to eliminate the icon element altogether as the 2 elements are the same underlying element.
āāThis is nice, but Iād think that much more important (and easier to implement) is the PRO Font Icon libraries.
First of all this is the exact right direction you need to be going with feature releases. Look at all the annoying workarounds people are doing (including downloading common plugins with lots of downloads, e.g. JSON parsing) and then integrate them into the baseline experience.
While this has almost everything you need from a button element, it would be nice to control the button and text padding separately. Right now if I want a āmove arrow to the rightā hover effect, thatās only possible by using a group and playing around with conditional padding. You canāt do it with the āGapā setting alone because that moves the text to the left.
Edit: @nick.carroll Does this mean we can delete the Material Icons plugin from our app? I donāt want a duplicate just sitting there.
Nice.
I would love to be able to define the icon conditionally by name. This way I could populate a buttonās icon with data from an option set or db.
Nice.
I would love to be able to define the icon conditionally by name. This way I could populate a buttonās icon with data from an option set or db.
Thanks for getting it done! The ability to choose the icon library is crucial. Without it, the feature might not be very practical. Iāll test it next week to see if it performs as well as it seems.
This is a great feature to finally have, weāve been using custom code to implement this in buttons instead of using groups.
It would be great if you added lucide icons, preferably instead of feather IMO. Itās a community maintained fork of feather icons and has a wider variety of icons and is more actively maintained. Even the original creator of feather recommends them now.
Lot of really great suggestions above about how to improve this but I think this is still an excellent release as it is.
Small bit of feedback, and Iām sure you guys have debated this length internally, but I think the button content layout settings should live in āAppearanceā rather than āLayoutā.
I say this because for a full 2min I was wondering where the heck is the Icon Placement setting.
I see Layout as determining how the overall container should behave and Appearance as related to the content.
Repeating groups have their column settings etc in Appearance rather than Layout which is consistent with this.