Closed pi0 closed 5 years ago
So I know there have been a lot of proposals for additional components (myself included), but I vote for this lib to keep a fairly tight focus on implementing just the BS4 catalog. I haven't maintained a big open source lib before, but everyone always says the hardest part is keeping it focused and avoiding unnecessary bloat.
Is that what you mean by "enhanced components"? Most of the issues I've seen with the current component set seem more like bug fixes so components play nice with each other and the outside world.
Aren't all the components already in a single repo?
If you were able to scaffold testing, I would help PR tests to cover the current functionality. I'm not super experienced with setting up a testing environment, but writing them is not a problem.
@alexsasharegan About tests there is an open Issue #161 . (Spoiler: We even already had an sponser offer from BrowserStack to provide us free Infrastructure) I can implement tests workflow for both e2e and unit test but that needs lots of time/contribution effort to write all tests. If you guys have enough time i can do this.
About keeping single repo but separate builds i think this can help keep track of core changes easier and tests can run for each core component change against all official extra components. I'm always open to and rely community so this won't make any development bottleneck and would provide more quality and faster iterations.
Also about enhanced components term, i talk about components composed of core ones such as date picker & tables (with built-in pagination etc) that can't be just added to core base.
If all the components were included in the same repo, wouldn't tree shaking simply not bundle the components that aren't used in a project?
Anyway, whatever option you decide @pi0 is good:
bootstrap-vue
repobootstrap-vue
organization@PierBover Tree shaking will work as long as we keep core components independent from extras and not referencing. Being in the same repo won't make any problems :) Currently i have created separate dist files. (bootstrap-vue.es.js
and bootstrap-vue.extra.es.js
) and extras are not included by default. I insist and recommend not even creating more repos in org because we may lose unit tests integration and it makes maintenance harder.
keeping a list of compatible components in other repos.
I agree about this too :)
I was working on revamping dropdown-select.vue
for ARIA, keyboard navigation, etc, and realized it is not a documented component, and isn't really a native bootstrap V4 component. Maybe this could be moved to components-extra
?
What are your ideas about contradicting the decision of the bootstrap team to not include a hover trigger for dropdowns? Looking at the popularity of this question it seems a lot of developers disagree with that decision. Proposed :hover
solutions you often find for this won't work well with vue-router
as the page is not reloaded after clicking a link in the menu so the menu stays visible and there is no way to close the menu programmatically. Would you accept a PR for a hover trigger in JS, similar like popover's?
Personally I don't like using the hover event because this assumes a mouse is being used, however I don't mind offering it as an option to developers. That's why Popover offers it.
How should one proceed to get a component listed as compatible? I have create vue bindings to the bootstrap-slider package, would be nice if it could be added.
And allthough you didnt knew, thanks for helping me with the build and test configs :1st_place_medal:
How should one proceed to get a component listed as compatible?
Would compatibility with Bootstrap 4 be the only requirement?
I'm considering building a date picker.
@PierBover Yep. You may also benefit core components if usable. PRs welcome for 1st extra component 🥇
Also, we may add docs dedicated for page other Vue + Bootstrap related projects like those @pimlie mentioned.
Just thinking about the directory structure for the extra components, and handling docs.
Maybe we should have the following structure:
/lib/components
/lib/directives
/lib/mixins
/lib/utils
/lib/extra
/lib/extra/components
/lib/extra/directives
/lib/extra/mixins
/docs
/docs/components
/docs/directives
/docs/extra
/docs/extra/components
/docs/extra/directives
or maybe this:
/lib/components
/lib/directives
/lib/mixins
/lib/utils
/docs
/docs/components
/docs/directives
/extra/lib/
/extra/lib/components
/extra/lib/directives
/extra/lib/mixins
/extra/docs
/extra/docs/components
/extra/docs/directives
or maybe make a docs
directory in each extra component:
/lib/components/extra/my-component/
/lib/components/extra/my-component/my-component.vue
/lib/components/extra/my-component/index.js
/lib/components/extra/my-component/docs/README.md
/lib/components/extra/my-component/docs/meta.json
/lib/components/extra/my-component/docs/index.js
That way all the related info about the component is placed into one compartment.
@tmorehouse I can handle it but just after closing currently pending PRs as this may make conflicts for everything :D
No problem. Just throwing a few ideas around :smile:
another option might be:
/lib/components/extra/my-component.vue
/lib/components/extra/my-component/
/lib/components/extra/my-component/README.md
/lib/components/extra/my-component/meta.json
/lib/components/extra/my-component/index.js
or (keeping current directory structure, but adding a sub-directory per component for docs)
/lib/components-extra/my-component.vue
/lib/components-extra/my-component/
/lib/components-extra/my-component/README.md
/lib/components-extra/my-component/meta.json
/lib/components-extra/my-component/index.js
@pimlie I'm quite interested by a slider component too. Any news/PR about this one?
[edit] I actually found https://github.com/pimlie/vue-bootstrap-slider but I just can't webpack
/grunt
/whatever-compile-tool
my project.
The fact that bootstrap-vue does not require a toolchain is a great positive point
Speaking purely as a user, one of the things I appreciate about this project is how little extra CSS it adds on top of Bootstrap. This speaks positively to long-term maintainability and compatibility, which are top-of-mind considerations when identifying frameworks for any new project.
So please be careful with extensions and additions, not to lose that quality!
It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove. - Antoine de Saint-Exupéry
@inopinatus thanks!
We do have some CSS additions (i.e. for the custom file picker, and a few other components) to augment and override some shortcomings of the current Bootstrap V4.beta CSS... hopefully we can remove much of that when Bootstrap V4.beta2 rolls out.
Some extra components are already available now but some further love to the existing ones would be a good idea.
IMHO this can be closed for now. Wether or not adding a new one could be discussed on a FR or PR basis.
Yeah. There are loads of 3rd party components that can work with bootstrap-vue.
Closing for now, and we can come back to this after our next stable release.
@jackmu95 , @tmorehouse , are there references to components that uses bootstrap-vue?
We don't have a list curated... but there are over 190 packages that depend on BootstrapVue (that are published to NPM), and there are some other packages that use Vue and Boootstrap v4.x CSS
There are too many components that aren't well designed for configuration (locale, styling, …), so I was hoping for some official maintained ones by the bootstrap-vue team to get the same level of great components.
Users require more and more enhanced components based on basic BS4 and we cannot add them to basic component set as it makes package bigger and bigger. Also we may keep release cycle / tests easier by keeping all components in a single repo. I'll start providing directory structure and necessary extra build steps for that. Please feel free to share your ideas and component requirements here. /CC @bootstrap-vue/dev