-
Notifications
You must be signed in to change notification settings - Fork 4
Open
Description
Bootstrap 5 has been around for a couple years, so it's high time we support it. I do have this "done" at an app level in one project, but promoting to the lib level is going to be a little tricky. Some things to think through:
- Bootstrap 4 will continue to be used in some projects. We should add a
KEG_BOOTSTRAP_MAJOR_VERSIONconfig option, and switch on that when needed - The form macro changes I made at the app level will cover CSS suggestions/fixes #183, so we can just fix that for BS5 and leave BS4 as-is
- Bootstrap no longer depends on jQuery, and IMO we should work to take jQuery out of our apps at this point
- We still use Select2 for form dropdowns. It is feature-flagged in via
KEG_USE_SELECT2 - I'd rather switch to TomSelect, use it with a separate feature flag, and adjust the select2 use to take the bootstrap version into account
- We still use Select2 for form dropdowns. It is feature-flagged in via
- Jinja block names have gotten a bit convoluted
- In the beginning, we used flask-bootstrap. That lib had opinionated block names in its base template, so we have historically used
stylesandscriptsblocks - Then came bootstrap-flask, which was less opinionated in that we had to use our own base template
- Then level12/keg-app-cookiecutter@c1dfe19 happened, breaking library-level script blocks on new projects.
- The upside of having consistently-named blocks within the base template is obvious - they are all under
bodyand are named accordingly - Unfortunately, keg-elements assumed otherwise, so select2, custom form JS, etc. didn't work out of the box
- Also, jinja doesn't give us the option of using variable names for blocks...
- The upside of having consistently-named blocks within the base template is obvious - they are all under
- Options to resolve
- This could be as simple as standardizing the lib on
body_scriptsand require apps to follow suit- That feels like the wrong approach. Apps shouldn't be dictating internal library code
- We could standardize on
keg_stylesandkeg_scripts, and require apps to put those blocks in an appropriate place in the base template- I like this approach better, as the libs already dictate some details of implementation
- I can envision order-of-inclusion issues, but that's a solvable issue IMO
- This could be as simple as standardizing the lib on
- In the beginning, we used flask-bootstrap. That lib had opinionated block names in its base template, so we have historically used
- Worth thinking about whether the library is too tied to Bootstrap
- I'm considering moving any templates that are Bootstrap-specific to a namespacing folder, and then adding a
KEG_TEMPLATE_FLAVORconfig option (defaults tobootstrap) - I believe jinja allows for variable use in include paths, so framework-agnostic generic templates could include the framework-specific version
- I'm considering moving any templates that are Bootstrap-specific to a namespacing folder, and then adding a
Metadata
Metadata
Assignees
Labels
No labels