Active
Project:
BS Base
Version:
2.x-dev
Component:
BS Base
Priority:
Normal
Category:
Plan
Assigned:
Unassigned
Reporter:
Created:
23 Apr 2020 at 10:29 UTC
Updated:
18 May 2026 at 17:47 UTC
Jump to comment: Most recent
Here we are planning version 2.x release.
Upgrade documentation from 1.x version is here.
General intention for 2.0 release is to update to Bootrstrap 5, clean and improve curent code and keep adding new features to a minimum.
Comments
Comment #2
pivica commentedComment #3
pivica commentedComment #4
pivica commentedComment #5
pivica commentedComment #6
miro_dietikerAbout components: We need to find a process to deal with components that are distributed across multiple origin repositories.
If you have a Website and a Shop area, you don't want to load the shop related assets everywhere. With many optional parts, the global monolythic asset is getting huge.
Loading too many micro components contextually also seems to be the wrong approach as this leads to too many different CSS aggregation variations. Then caching them doesn't work.
So the framework and patterns we recommend should result in chunks of separation that make sense, where you can deal with larger optional components and still benefit from feasible stable static asset caching.
Comment #7
pivica commented> About components: We need to find a process to deal with components that are distributed across multiple origin repositories.
Some initial thoughts
The pattern approach is defining atoms, molecules, organisms, templates and pages.
Bootstrap is defining layout, content, components and utilities https://getbootstrap.com/docs/4.4/getting-started/introduction/.
Bootstrap content is mostly atoms from my perspective. Bootstrap components are molecules and some atoms (for example button is an atom for me).
Bootstrap layout and utilities are similar i would say. We do not use layout by default in a base theme and we use some utilities, we let child theme define layout rules as they like and load additional utilities as needed. I don't see any problem with this approach currently and would keep this if others are not objecting, and try to keep minimal utility loading as much as possible.
It makes sense to me we always load all atoms and molecules styles by default.
Organisms are stuff like header, footer, nodes, etc. We should probably define libraries for styles/behaviours and load these libraries in respective organism templates.
In this way, shop card and shop product page styles would be loaded only if/when they are needed.
Thoughts?
Comment #8
pivica commentedComment #9
pivica commentedComment #10
pivica commentedComment #11
pivica commentedComment #12
pivica commentedComment #13
pivica commentedComment #14
pivica commentedAdded 2.x branch so we can group issues more easily.
Comment #15
pivica commentedComment #16
pivica commentedComment #17
pivica commentedComment #18
pivica commentedComment #19
pivica commentedComment #20
pivica commentedComment #21
pivica commentedComment #22
pivica commentedComment #23
pivica commentedComment #24
pivica commentedComment #25
pivica commentedComment #26
pivica commentedComment #27
pivica commentedComment #28
pivica commentedComment #29
pivica commentedComment #30
pivica commentedComment #31
pivica commentedComment #32
pivica commentedComment #33
pivica commentedComment #34
pivica commentedComment #35
pivica commentedComment #36
pivica commented