One role per component requires the user to repeat design instructions.
I would like to be able to list my own CSS classes and possibly disable the ones already applied.
Repeats occur when a slight modification between almost entirely identical roles is required, e.g. big button and small button that have identical design, but differ in size would need all of the code repeated for the sake of changing size. You could wrap it in a parent and specify parent specific size, but it’s yet another layer of divs to manage.
This is what I built, wanting small glass cards inside big glass cards, but it was unnecessarily hard, and even now the shadows are cropped a little not matching my codepen design.
I would like Properties > Appearance to include a field for classes that can be listed with a space between them. I would also like a way to remove existing classes.
Happy to hear your approach to this in case there are already features that can help me with that. I could apply classes through the anvil.js approcah, but I would like to see results live, and not have to re-run the app all the time.
This would trully allow me to design sites faster and without playing whackamole with odd CSS prioritization.
Since you mentioned the anvil.js approach, but didn’t mention the multiple roles approach,
I just wanted to mention that from the ide you can assign only one role per component, but from code you can assign also a list of roles (a list of strings).
I often create roles that change only a few properties and assign them from code. For example but.role = ['withshadow', 'small'] rather than but.role = 'withshadow-small'.
This allows to reduce the wild proliferation of roles, but it can’t be used at design time.
It would be nice to be able to select multiple role names from the drop down in the properties section.
So, turning the list of roles into a simple checklist wouldn’t necessarily suffice. They might not be listed in the necessary order. Could a full or partial ordering be specified, so that a checklist would always work? (Such a specification would be very useful for documentation, too.)
Edit: Considering how messy this can get – should picking a Role automatically prevent conflicting Roles from being picked? – I’m starting to understand why it’s a “pick just one” by default…
Given its ability to specify HTML directly, would the HTML Form be useful here, perhaps as a building block?
This could be the new interface, with the multi-select drop down with the selected roles, plus, available after expanding with MORE, a textbox with the list of classes.
Being able to set the order of multiple roles would be nice, but I think that in the few cases it does make a difference, having access to CSS classes would be a good enough workaround.
I ended up making quite a few button blocks like that, so that I can reuse them as components. The issue of designing them was still limited by 1 role though.
I also suggested that Anvil gets custom component development a more intense look as a kit you could buy and sell on the Anvil marketplace if such a thing is possible in the future.
I really like Anvil, but it is lacking in design tools. That said, there is a reason why I pay for Anvil instead of webflow that can do design well, and also not bubble with their ridiculous prices which Anvil competes with very well.
I would go as far as saying let’s not break working elements for new users and let them enjoy 1 role, by keeping that row as is with its dropdown. It works and it’s great.
We literally just need a box that will paste those classes in the class=“” section.
Challenges I forsee:
Auto refresh of the design window (code exists to do that with a slight delay, just edit theme and go back to the form it shows up immediately)
Decision to be made on activating precedence over roles or not.
Components like button are not a button in code, rather div div button. Where should the class be applied and how will this be communicated?
Possibly python side integration issues where the variable self.item.classes will need to be an array, I am not sure that pattern exists in other fields yet.
I misunderstood, yes you can get away with quite a bit by writing classes directly in your elements.
On the but side: it’s not elegant or user friendly to modify those classes during execution, where I had to use anvil.js and create a “hook” for each field and it’s onclicks. At that point I almost need to code the site from scratch elsewhere and then copy paste the code into Anvil, where I would link it up to the databases. I’d rather do it with the amazing python driven philosophy Anvil has.
And another but, possibly due to my current lack of front end experience, Anvil overrides a lot of what I am trying to put in my classes with material or bootstrap or default CSS they have in the app by default. I have to put out fires and constantly wonder why the shadow here or there didn’t work.
Well… we already have multiple selection in roles from code, we only miss it on the UI. And the fact that it’s missing in the UI is the very reason why many users don’t even know it’s possible to assign a list of roles.
I use multiple roles from code often. When the list of roles became available, I refactored old apps that had proliferation of role combinations like selected-red, selected-red-disabled, selected-disabled, red-disabled, etc. and created only 3 roles selected, red and disabled. Everything is much simpler, but I can’t use the dropdown in the IDE and I need to run the app to see what my components will look like at run time.
Mmmmh. now that I think about it, requiring manual creation of roles, is bad for two reasons: because it’s annoying (I agree with you) and because it’s error prone. You risk to create a role in the Roles page and its definition in the CSS with mismatching names.
The list of roles should be automatically generated by analyzing the CSS classes. There should be one role for every CSS class with a name starting with anvil-role-.
All the roles should appear in the Roles window with default values in the Show in toolbox and the Restrict components settings, so you could go there and change their settings. The yaml file should only list the roles that have been customized.
I would also change the Roles page from the current list of forms to a table. It would be more compact, would immediately give an idea of what’s going on without requiring any wild scrolling and (in my opinion) would be more user friendly. Especially if the columns were searchable and sortable.
Perhaps if roles were automatically created and with the multi-selection you would be happy, even without direct access to all the CSS classes?
One last point about prioritization of class/role vs theme.
Direct example: last time I tried to add a role to a button component a lot of settings related to margin and size in the role were ignored in favor of bootstrap theme element design. Having more know-how now I will try again to do it the standard way, and also use something like [anvil-role]=navigation_menu {} instead of .anvil-role-navigation_menu {}.
