Hi

What is the status of bootstrap-vue and Vue 3? I know Vue 3 is just in beta now. But I see no statement or other on your page if/how/when you are going to support Vue 3.

With kind regards, Johan

Adds async provider function support (callback and Promise based)

Deprecates items-provider in favour of passing function to items prop

Adds scoped slot support for table header and footers

Added busy prop for triggering table "busy" state (via `aria-busy="true" attribute).

Emits head-clicked event when header cells are clicked (when not busy), and a refreshed event when the provider function has completed/resolved.

Added sort-changed event when sorting criteria has changed

Added extra documentation.

A working prototype example can be found here: https://jsfiddle.net/dyzs5txk/ (complete with header/footer scoped slots). You can select how the items are provided to b-table (view the console for the various stages of data retrieval). The example requires a browser that supports Promises (just to emulate the delay in fetching data).

The updated documentation provides greater detail on the new features

When I copy example (https://jsfiddle.net/pi0/bofh9aaa) locally, it does not work on bootstrap 4.0.0-alpha.6 and bootstrap-vue 0.14.0. I get only a blackout of body.

:question: What is it?

Version of Bootstrap-Vue which works for Vue 2 and Vue 3 (using @vue/compat) Helps people with #5196

Demo using Vue 2 Demo using Vue 3

Additionally, it passes all (well, almost all, tiny fraction of tests are disabled because they are irrelevant for vue 3) tests in the test suite (it would be literally impossible to do this migration without a test suite)

This package uses vue 3 by default. If you want to run tests, build, etc. using vue 2 pass USE_VUE2=1 environment variable

:exclamation: How is this possible?

The heart of this PR consists of two parts:

• new vue-test-utils-compat package which allows us to run old test suite using new Vue (it's like @vue/compat but for tests
• Additional compatibility layer for Vue3 crafted specifically for bootstrap-vue

:wrench: How could I run it?

If you want just to play around - you can clone https://github.com/xanf/bootstrap-vue3-demo which has all required setup. If you want to try it on your own project, there is some setup required.

I'm skipping setup of @vue/compat, it is described in migration guide

You will need to monkey patch your Vue 3 a bit somewhere early in your app:

  const originalVModelDynamicCreated = Vue.vModelDynamic.created;
  const originalVModelDynamicBeforeUpdate = Vue.vModelDynamic.beforeUpdate;
  Vue.vModelDynamic.created = function (el, binding, vnode) {
    originalVModelDynamicCreated.call(this, el, binding, vnode);
    if (!el._assign) {
      el._assign = () => {};
    }
  };
  Vue.vModelDynamic.beforeUpdate = function (el, binding, vnode) {
    originalVModelDynamicBeforeUpdate.call(this, el, binding, vnode);
    if (!el._assign) {
      el._assign = () => {};
    }
  };

See https://github.com/vuejs/vue-next/pull/4121 for details

If your intention is to run your app in { MODE: 2 } (default @vue/compat) you're done. If you want to have { MODE: 3 } (so all compats are disabled by default), additional setup is needed:

• if https://github.com/vuejs/vue-next/pull/4974 is not yet merged - you need to build @vue/compat build with this fix included. https://github.com/xanf/bootstrap-vue3-demo already has patch inside patches folder for that, installed by patch-package
• Certain compat flags required to be enabled globally ATM and can't be disabled in this release (which maintains Vue 2 and Vue 3 compatibility):
  • GLOBAL_EXTEND, GLOBAL_MOUNT - for using new Vue inside bootstrap-vue
  • COMPONENT_FUNCTIONAL, RENDER_FUNCTION
  • CUSTOM_DIR (anywhere where you use bootstrap-vue directive)

If you use portal-vue (which is still used for tooltips, etc.) you will need:

• GLOBAL_SET

If you use old (for Vue 2) version of vue-router you will need:

• CONFIG_OPTION_MERGE_STRATS
• GLOBAL_PRIVATE_UTIL
• GLOBAL_PROTOTYPE
• INSTANCE_EVENT_HOOKS
• OPTIONS_DESTROYED
• INSTANCE_EVENT_EMITTER

:bomb: What might not work

• Docs. I've tried to make Nuxt run using newer Nuxt 3, bridge, etc. but it was very problematic. So I wrote a script, which extracted demos from docs and generated https://github.com/xanf/bootstrap-vue3-demo with all demos
• Build. It might or might not work, I didn't have an opportunity to test it yet

:arrow_upper_right: What's next?

Let's treat this one as "bridge" version Based on this branch I will create another one, which will be focused solely on full vue 3 compatibility (without using @vue/compat). While this will definitely take time, right now I do not see any major obstacles in gradual migration

:hugs: That's cool, how could I say "thank you"?

You're welcome, it's all about opensource. However, there are certain things, where your help will be appreciated:

• Help me spread the word about vue-test-utils-compat. You can retweet me or just drop a link to your friend who could be interested
• Check deployed versions of https://github.com/xanf/bootstrap-vue3-demo (links inside) and report about any issues you find out in Vue 3 version (it is very time consuming to test all possible scenarios)

PR checklist

What kind of change does this PR introduce? (check at least one)

• [ ] Bugfix (fixes a boo-boo in the code) - fix(...), requires a patch version update
• [x] Feature (adds a new feature to BootstrapVue) - feat(...), requires a minor version update
• [ ] Enhancement (augments an existing feature) - feat(...), requires a minor version update
• [ ] ARIA accessibility (fixes or improves ARIA accessibility) - fix(...), requires a patch or minor version update
• [ ] Documentation update (improves documentation or typo fixes) - chore(docs), requires a patch version update
• [x] Other: major update

Does this PR introduce a breaking change? (check one)

• [x] No (I know it's hard to believe)
• [ ] Yes (please describe since breaking changes require a minor version update)

The PR fulfills these requirements:

• [x] It's submitted to the dev branch, not the master branch
• [x] When resolving a specific issue, it's referenced in the PR's title (i.e. [...] (fixes #xxx[,#xxx]), where "xxx" is the issue number)
• [x] It should address only one issue or feature. If adding multiple features or fixing a bug and adding a new feature, break them into separate PRs if at all possible.
• [x] The title should follow the Conventional Commits naming convention (i.e. fix(alert): not alerting during SSR render, docs(badge): update pill examples, chore(docs): fix typo in README, etc.). This is very important, as the CHANGELOG is generated from these messages, and determines the next version type (patch or minor).

If new features/enhancement/fixes are added or changed:

• [ ] Includes documentation updates
• [ ] Includes component package.json meta section updates (prop, slot and event changes/updates)
• [ ] Includes any needed TypeScript declaration file updates
• [ ] New/updated tests are included and passing (required for new features and enhancements)
• [x] Existing test suites are passing
• [x] CodeCov for patch has met target (all changes/updates have been tested)
• [x] The changes have not impacted the functionality of other components or directives
• [ ] ARIA Accessibility has been taken into consideration (Does it affect screen reader users or keyboard only users? Clickable items should be in the tab index, etc.)

If adding a new feature, or changing the functionality of an existing feature, the PR's description above includes:

• [x] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

With this commit we support vertical tabs by setting <b-tabs position="left" or <b-tabs position="right". The boolean property bottom has been removed as that would be redundant.

The only issue I still have is using the card property with postition left or right. It seems the card-block class has preference over the col class causing the tab-content div to have a width of 100% and being displayed underneath the list of tabs. Not sure what the best solution to this is, any recommendations would be appreciated

Per the conversation on issue #516 and it's PR #517, this proposes a more granular link mixin. This allows components that consume part of the internal link component API to automatically stay up to date with proxying all the link props down to the b-Link component itself.

Description of Pull Request:

Allow user to select rows. As this only works for visible rows, this feature doesn't rely on item keys.

see #1790

PR checklist:

What kind of change does this PR introduce? (check at least one)

• [ ] Bugfix
• [x] Feature
• [ ] Enhancement to an existing feature
• [x] ARIA accessibility
• [x] Documentation update
• [ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

• [ ] Yes
• [x] No

If yes, please describe the impact:

The PR fulfills these requirements:

• [x] It's submitted to the dev branch, not the master branch
• [x] When resolving a specific issue, it's referenced in the PR's title (i.e. fixes #xxxx[,#xxxx], where "xxxx" is the issue number)
• [x] The PR should address only one issue or feature. If adding multiple features or fixing a bug and adding a new feature, break them into separate PRs if at all possible.
• [x] PR titles should following the Conventional Commits naming convention (i.e. "fix(alert): not alerting during SSR render", "docs(badge): Updated pill examples, fix typos", "chore: fix typo in docs", etc). This is very important, as the CHANGELOG is generated from these messages.

If new features/enhancement/fixes are added or changed:

• [x] Includes documentation updates (including updating the component's package.json for slot and event changes)
• [ ] New/updated tests are included and passing (if required)
• [x] Existing test suites are passing
• [x] The changes have not impacted the functionality of other components or directives
• [x] ARIA Accessibility has been taken into consideration (does it affect screen reader users or keyboard only users? clickable items should be in the tab index, etc)

If adding a new feature, or changing the functionality of an existing feature, the PR's description above includes:

• [ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Describe the bug

I updated my nuxt project to the latest release which is 2.14. I then use nuxt generate to build the project. While nuxt is building the project, it gives this error

[BABEL] Note: The code generator has deoptimised the styling of \node_modules\bootstrap-vue\src\icons\icons.js as it exceeds the max of 500KB.

Steps to reproduce the bug

1. Update the project to 2.14
2. Use nuxt generate to build project
3. It will display the error when compiling on the Client

Expected behavior

Should not have any errors

Versions

Libraries:

• BootstrapVue: 2.16.0
• Bootstrap: 4.5.0
• Nuxt: 2.14.0

Should all components have a default b_UID on the parent container (if no ID provided)?

And if so, should IDs be "dynamic/reactive" or static once set?

Something like this?

  data() {
    return {
      thisId: this.id || ('b_' + this._uid )
    };
  },
  props: {
    id: { 
      type: String,
      default: null
    }
  }

And if IDs are required for other elements within the component they can be based on thisId:

<template>
  <div :id="thisId">
     <span :id="thisId + '_myspan'">Some element</span>
     <div :id="thisId + '_mydiiv'">Some other element</div>
     <div>This one doesn't need ID</div>
  </div>
</template>

Bootstrap V4 is addressing some of the accessibility issues: https://github.com/twbs/bootstrap/issues/22549, Of which bootstrap-vue has started to already address.

Here is little list of items that are complete or need work for aria and/or keyboard navigation (to be updated as we progress through them):

Components - ARIA / Keyboard Navigation

• [x] b-form-radio input wrapped in label (which negates need for for on label)
• [x] b-form-checkbox input wrapped in label (which negates need for for on label)
• [x] b-progress ARIA progress attributes
• [x] b-modal attributes aria-labelledby and aria-describedby. Section roles & semantic elements. (PR #247)
• [x] b-modal Focus first input/button on open (PR #247). Allow page author to specify input to be focused when opened via @shown event (PR #378)
• [x] b-modal focus the modal content when opened
• [x] b-tabs & b-tab attributes aria-controls and aria-labelelledby. Section roles (PR #339)
• [x] b-tabs & b-tab keyboard navigation (PR #339)
• [x] b-alert has aria role="alert", aria-live and aria-atomic (PR #340)
• [x] b-form-file Needs focus styling in custom-file-input mode for keyboard users (PR #1033)
• [x] b-form-fieldset attribute for when ID supplied on ,form-control. Has role="alert", aria-live, aria-atomic on feedback. and aria-describedby (PR #340)
• [x] b-breadcrumb ~should have role of navigation (PR #340)~ Add aria-current to active crumb (PR #526)
• [x] b-input-group needs role="group" (PR #340)
• [x] b-button-group role="group", make new toolbar component (PR #367)
• [x] b-button-toolbar role="toolbar" + optional keyboard navigation (PR #367)
• [x] b-nav & b-nav-link aria attributes (PR #358)
• [x] b-dropdown keyboard navigation (PR #274)
• [x] b-nav-dropdown aria- attributes (PR #358)
• [x] b-nav-dropdown open on ENTER or SPACE (see Issue #348) (PR #349)
• [x] b-nav-toggle aria- attributes (PR #358, #410, #411, #412)
• [x] ~~b-nav & b-nav-link keyboard navigation~~ (leave as standard TAB key navigation)
• [x] b-collapse Reflect expanded/collapsed state on trigger element (PR #358 & #519)
• [x] b-pagination aria-[label|current|setsize|posinset] attributes. (Note: aria-controls should be set manually in the <b-pagination>markup) (PR #364)
• [x] b-pagination keyboard navigation (PR #364 & #377)
• [x] b-carousel aria-[controls|label|current|setsize|posinset] attributes and roles. (PR #380)
• [x] b-carousel keyboard left/right control (PR #380, #420)
• [x] b-carousel Pause slide scrolling on mouseenter and resume on mouseout.
• [x] b-tooltip aria- attributes (aria-live, aria-describedby, etc
• [x] b-popover aria- attributes (aria-live, aria-describedby, etc. Also needs ability to change role from tooltip to popover or dialog
  • Popovers can have some issues with regards to accessibility, especially for interactive popover content, and possibly should have a role other than tooltip (configurable). https://github.com/twbs/bootstrap/issues/18618

Directives

• [x] v-b-modal return focus to open trigger element.
• [x] v-b-toggle attributes aria-controls and aria-expanded. (PR #519)

Documentation

• [x] Create ARIA best practices for Bootstrap-Vue - sections added to each compoent
• [x] Add documentation where needed

• Deprecate slot text in favour of slot button-content(addresses issue #617)
• Migrated data(), common props, methods & clickout into dropdown mixin
• Removed prop link as setting variant="link" does the same thing
• Removed undocumented <b-button-group-dropdown> in favour of using <b-dropdown>

Bumps actions/cache from 3.0.11 to 3.2.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps marked from 2.0.3 to 4.2.5.

You can trigger a rebase of this PR by commenting @dependabot rebase.

Documentation issue

• [ ] Reporting a typo
• [ ] Reporting a documentation bug
• [ ] Documentation improvement
• [ ] Documentation feedback How can we set custom pages when select first page and last page button?

I upgrading my Vue 2 project to Vue 3 (BootstrapVue with @vue/compat). I cannot bind data correctly when using "b-form-tags". I setup a Demo. In this demo contains 2 "b-form-tags" elements, once is using v-model (id:tags-basic) and another one is no binding (id:tags-basic2), when I try to input value in (id:tags-basic), the array always contains the first character but another one (id:tags-basic2) is no problem.

Describe the bug

I define the default settings like it is described in example 3 from the documentation (https://bootstrap-vue.org/docs/reference/settings#setting-config-via-individual-component-group-plugin-imports). For localization I use vue-i18n, also in the default settings. Changing the language by an user does not show any effect in the bootstrap components.

Steps to reproduce the bug

Vue.use(VueI18n);

const i18n = new VueI18n({
    messages: {
        de: {
            no_items_found: 'Keine Eintrage gefunden'
        },
        en: {
            no_items_found: 'No items found'
        }
    },
    locale: 'de',
    fallbackLocale: 'en'
});

Vue.use(BVConfigPlugin, {
    BTable: {
        emptyText: i18n.t('no_items_found')
    }
});

when calling i18n.locale = 'en' the emptyText will remain in German

Expected behavior

Components should show the correct translations.

Versions

Libraries:

• BootstrapVue: 2.23.1
• Bootstrap: 4.6.2
• Vue: 2.7.14

Am I doing something wrong? Changing the language is working for the rest of the frontend, but for the defaults. Or is there a better way to set the defaults?

Bumps qs from 6.5.2 to 6.5.3.

You can trigger a rebase of this PR by commenting @dependabot rebase.