Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

Implement a uniformed 'interface' for plugins #39

Closed
VizuaaLOG opened this issue Jun 14, 2018 · 0 comments
Closed

Implement a uniformed 'interface' for plugins #39

VizuaaLOG opened this issue Jun 14, 2018 · 0 comments
Labels
in-progress is-breaking-change
Milestone
0.7.0

Comments

@VizuaaLOG
Copy link
Owner

In order to create an easy and simple Javascript API there needs be a unified naming convention among the official plugins. Some kind of interface to follow.

Some ideas for these interface 'rules' could be:

  • All plugins will have a static create method, this is used by the Bulma.create method and if not required can simply return false
  • All plugins will have a static parse method, this is used by the BulmaJS core when parsing the HTML DOM and if no data API is provided can simply return false
  • All plugins will have a static rootClass method, this is used by the BulmaJS core when parsing the HTML DOM and is used to identify the primary class the plugin is responsible for. E.g. notification
  • All plugins will have a parent method/option, this is the HTML element the plugin is being placed into. A notification may have a div as it's parent whereas a modal may use the body element
  • All plugins will provide a static defaultOptions object that will be responsible for holding the default options for the plugin. This will be required for an update to the core that will merge the provided options, either via JS or data attributes, with the default options
@VizuaaLOG VizuaaLOG added this to the 0.7.0 milestone Jul 29, 2018
@VizuaaLOG VizuaaLOG mentioned this issue Oct 9, 2018
Merged
VizuaaLOG pushed a commit that referenced this issue Oct 13, 2018
Create an abstract plugin class closes #39
16c76cd
VizuaaLOG pushed a commit that referenced this issue Oct 14, 2018
Create an abstract plugin class closes #39
ab73801
VizuaaLOG pushed a commit that referenced this issue Jun 23, 2019
Feature/base plugin (#55)
a956bcc 
* Update build deps

* Create an abstract plugin class closes #39

* Update the navbar plugin to use the base plugin

* Update the accordion plugin to use the abstract plugin class

* Adjust order of options

* Update the calendar plugin to use the new plugin interface

* Update the dropdown plugin to use the plugin interface

* Update the file plugin to use the plugin interface

* Move static methods to the top of the file for consistency

* Update the dismissableComponent, message and notification to use the plugin interface.

* Update the modal plugin to use the updated plugin interface

* Update the tabs plugin to use the new plugin interface

* Rename the dom parsing method, and fix a bug introduced with the priority feature
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
in-progress is-breaking-change
Projects
None yet
Milestone
0.7.0
Development

No branches or pull requests
1 participant
@VizuaaLOG