- Introduction
- Migrating from v6.x.x to v7
- JavaScript
- Which format should you choose?
- What is the difference between MDB ES and UMD formats in MDB?
- Using charts with ES import
- About the initMDB method
- How to use the initMDB method?
- Initialization: Components, Plugins, Events & Methods
- LINKS
Introduction
MDB package went thought serious refactor and unification process. From file method and event names to compiled file names. We've changed a lot of things to make MDB more consistent and easier to use. Below you can find a list of the most important changes.
Note: The following list is not complete. Only the most key changes are listed, but you should bear in mind that no component has remained unchanged.
Migrating from v6.x.x to v7
After updating the MDB Standard from version 6 to 7, there is a lot of breaking changes that must be introduced in existing projects to keep them stable. These changes relate in particular to data attributes, events and method names, compiled file names.
We also made some changes that are not visible to users but affect final product. We've changed bundler that compile files to Vite which allows smaller weight of the package after compilation.
We move from preparing files with compiled modules for every component to using ES modules. Our package will no longer include premade JavaScript modules. That change does not apply to plugins.
In the same fashion we won't include CSS modules anymore. To reduce bundle size of CSS in your project we recommend the use of PurgeCSS. Our tutorial for including PurgeCSS in yur project is available here.
Charts became separate file now which makes no difference when migrating to UMD format, but if user is going to use ES imports then charts needs to be imported from chart.es.min.js file as separate module.
JavaScript
There was a lot of changes to our source and compiled JavaScript files. We are going to no longer include in the package files with compiled modules for every component.
In the new version we are introducing new, modular approach. Now user will be able to use ES or UMD formats for all components. These formats will differ in the way components are initialized and will be used in different cases.
Which format should you choose?
If your application:
- Is based on modules
- Uses bundler functionality
- Needs treeshaking
The ES format will be most suitable for you, otherwise UMD is the way to go.
What is the difference between MDB ES and UMD formats in MDB?
In short, the way to initialize components. In order to allow bundlers to perform proper treeshaking, we have moved component initialization to the initMDB method. MDB in UMD format will work without adding more elements, but will lack treeshaking. MDB in ES format, on the other hand, allows components to be used as separate modules, resulting in the much smaller build size.
If you are not using bundlers, you should use the UMD format.
Using charts with ES import
The mdb.es.min.js does not include charts component. If you plan to use charts within your project, when using ES import, charts needs to be imported from chart.es.min.js file as separate module.
About the initMDB method
To use the initMDB method, you need to import it from the mdb-ui-kit, same as for components. You can provide a second argument that will be an object with options that you want to pass to the init method.
How to use the initMDB method?
Import the method from the mdb-ui-kit package inside your project js file and call it with the components you want to initialize.
JAVASCRIPT
import { Datepicker, Input, initMDB } from "mdb-ui-kit";
initMDB({ Datepicker, Input });
Initialization: Components, Plugins, Events & Methods
To initialize component we are now using data attributes unified through all components and plugins. Attribute is created using pattern data-mdb-{component-name}-init e.g. data-mdb-input-init. With UMD import that is all what is needed to run component. With ES import there is a need to allow auto init with initMDB method for component used on the page. More about that in this section.
And because this article is already of gargantuan length, below you will find the link for the full Migration Guide, where every Components, Plugins, Events & Methods is described in detail.
Top comments (0)