blitzar
blitzar copied to clipboard
feat(docs): add example of custom style [3h]
- [ ] add an example of a form with custom style
- [ ] think about how this can be improved in the first place
the style really is in what components you use and not much more. I guess I can think of some creative ways using nice field background colours, but I'd say this is low priority for now.
But there is a "style" in the layout scaffolding around the components in schema: the concept of columns, blitz-field, blitz-field__label, etc., don't you think?
I don't have particular complaints about the wrapper of the blitz form/field/grid, but just thinking about potential customization in future...would there be a way to abstract that scaffolding such that it could be configured somewhere, maybe in a central UI Schema that just handles the grid and field-wrapper, so that one could use Vuetify, Bootstrap, Apple's HIG, etc.,?
@eyleron Yes, you are correct!
would there be a way to abstract that scaffolding such that it could be configured somewhere, maybe in a central UI Schema that just handles the grid and field-wrapper, so that one could use Vuetify, Bootstrap, Apple's HIG, etc.,?
I would love this as well. But I'm not sure how to best approach it yet.
How to currently style the wrapper of the blitz form/field/grid.
styling related settings via props:
labelPosition="left"/"top"(but overwritable with CSS) (docs)columnCount="2"/ etc. (on the form itself)span: true/span: 1(inside the schema on each field)gridGap="1em"not clear from the docs now how to set this via CSS- Currently you can set the amount of columns in a form, and then set a
spanon each field to determine how many columns it should span.
styling related settings via CSS:
- label positioning (docs)
- field styling (docs)
- targetable classes:
blitz-formblitz-fieldblitz-field__componentblitz-field__labelblitz-field__sub-label
Currently:
- Styling of the form grid is too "scattered" you need to set it up via a combination of form props / schema props / css...
Ideally:
- Styling of the form grid is more centralised.
- Can be configured either entirely through CSS, or entirely through a single object passed as prop.
- I prefer CSS because I believe anything styling related should dealt with in CSS.
- I love the idea of forcing people to use the grid-template-areas like so:
.my-form {
grid-template-areas: "title-1 title-1"
"field-a field-b"
"subtitle-1 subtitle-1"
"field-c field-c"
"field-d field-e"
}
.my-field {
grid-template-areas: "component label"
"sub-label sub-label"
}
Benefits of forcing the dev to use grid-template-areas:
- all settings are easily centralised in CSS, including grid-gap, no more span needed on fields, ...
- it's easy to have the dev create mobile versions as well via media queries
- allows fields to span vertically as well (currently not possible)
- the syntax makes it somewhat easy to imagine how the form will look like
Issues with the grid-template-areas approach:
- I'm not sure how to set up the
grid-areanames so it makes sense, having the dev provide agrid-areaname inside the schema for each field seems verbose. Automatically using theidfor thegrid-areaname is also not ideal because the ID may change and many "flavour" fields might have no ID. - large forms where the dev simply wants 3 columns and not mess around with the
grid-template-areasbecome a problem, because automatically assigning agrid-areato a field makes it so it doesn't fall into the correct spots when only using eg.grid-template-columns: "1fr 1fr 1fr"... any field with agrid-areawill be pushed outside of these... - I guess it's more difficult to accept CSS from a server to load custom user styles? But this issue is currently also present. Could be mediated by allowing the CSS to be passed as a prop to the form (a nested JS object).
Is there a way to style the field if he is not valid?
I would like to have a class like blitz-field__error so I can set a style in this cases.