Skip to content

Bootstrap 5 support #188

@guruofgentoo

Description

@guruofgentoo

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_VERSION config 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
  • 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 styles and scripts blocks
    • 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 body and 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...
    • Options to resolve
      • This could be as simple as standardizing the lib on body_scripts and require apps to follow suit
        • That feels like the wrong approach. Apps shouldn't be dictating internal library code
      • We could standardize on keg_styles and keg_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
  • 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_FLAVOR config option (defaults to bootstrap)
    • I believe jinja allows for variable use in include paths, so framework-agnostic generic templates could include the framework-specific version

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions