donotebase / quasar-tiptap

A modern WYSIWYG rich-text editor built on top of tiptap and Quasar for Vue.js.
https://donotebase.github.io/quasar-tiptap
MIT License
309 stars 61 forks source link

Use quasar iconSet instead of hardcoded icons #12

Open larvanitis opened 4 years ago

larvanitis commented 4 years ago

Currently, the component icons are hardcoded to material-icons and mdi names, which means that (a) they are not configurable and (b) both sets must be loaded.

For example, in this component, code uses material-icons, while code_block uses mdi.

https://github.com/donotebase/quasar-tiptap/blob/10a60d629385d025f2dd5bf6774533e8f018e173/src/components/buttons/OSimpleCommandBtn.vue#L47-L48

IMHO the icons should resolve, in that order, to:

  1. a user configured icon
  2. the selected iconSet icon
  3. the selected iconSet "polyfill" icon
  4. a hardcoded fallback

(1) global plugin config or per component? - eg. something like userIconSet.editor.bold (2) eg. this.$q.iconSet.editor.bold (3) quasar-tiptap could bundle iconSet extensions for the official ones - eg. iconSetExtensions[this.$q.iconSet.name].editor.bold (4) the fallback could be one of the official iconSets (eg. mdi)

The icons themselves fall into one of these categories:

Overall, I believe the best solution would be to define a quasar-tiptap custom iconset, used by all components. It will define its own semanticly named icons, mapped to icons according to the logic I described above.

So it might look something like this:

const qtIconSet = {
  // ...
  formatBold: opt.iconSet.formatBold || this.$q.iconSet.editor.bold || polyfills[this.$q.iconSet.name].formatBold || defaultIconSet.formatBold,
  // ...
};

Then all components could import and utilize qtIconSet. Bonus points if defaultIconSet contains inline svgs so that no set is required.

mekery commented 4 years ago

Currently, the component icons are hardcoded to material-icons and mdi names, which means that (a) they are not configurable and (b) both sets must be loaded.

For example, in this component, code uses material-icons, while code_block uses mdi.

https://github.com/donotebase/quasar-tiptap/blob/10a60d629385d025f2dd5bf6774533e8f018e173/src/components/buttons/OSimpleCommandBtn.vue#L47-L48

IMHO the icons should resolve, in that order, to:

  1. a user configured icon
  2. the selected iconSet icon
  3. the selected iconSet "polyfill" icon
  4. a hardcoded fallback

(1) global plugin config or per component? - eg. something like userIconSet.editor.bold (2) eg. this.$q.iconSet.editor.bold (3) quasar-tiptap could bundle iconSet extensions for the official ones - eg. iconSetExtensions[this.$q.iconSet.name].editor.bold (4) the fallback could be one of the official iconSets (eg. mdi)

The icons themselves fall into one of these categories:

  • "Action" defined in Quasar iconSets, found in current theme -> use iconSet (2)
  • "Action" defined in Quasar iconSets, not found in current theme -> use polyfill (3)
  • "Action" not defined in Quasar iconSets

Overall, I believe the best solution would be to define a quasar-tiptap custom iconset, used by all components. It will define its own semanticly named icons, mapped to icons according to the logic I described above.

So it might look something like this:

const qtIconSet = {
  // ...
  formatBold: opt.iconSet.formatBold || this.$q.iconSet.editor.bold || polyfills[this.$q.iconSet.name].formatBold || defaultIconSet.formatBold,
  // ...
};

Then all components could import and utilize qtIconSet. Bonus points if defaultIconSet contains inline svgs so that no set is required.

Good idea, I'll define a quasar-tiptap custom iconset.