Is it possible to inherit/extend a core field?

[random-one]

Hello,
my question is if it's possible to inherit(using extends) for example the fieldSelect just to include something in its templatе?
I don't want to just copy the whole field code and modify it for my needs and use it as a custom field. I think it would be possible if we could import the fieldsComponents themselves. Right now in my opinion only the abstractField mixin is exposed and used when defining custom fields, but that is not my case.

My problem with copying the fieldSelect and using it as custom field is that when at some point a newer version of vue-form-generator fixes something or improves the component, my copy of it has to be maintained by me and manually updated to incorporate the fixes or improvements.

Any thoughts on this @icebob?

[lionel-bijaoui]

As far as I know, this is impossible with the current system. There could be a way by using mixins but this is currently not the way this plugin work*.
You are better of copying the source code and adapting it to your need.
Sorry that this is not the answer you where looking for.

---

*Most of the code for the fields are shared in the abstractField.js. Of course, adjustment needs to be made for every fields depending on it's functionality but it give them a common ground for the I/O and data logic.
VFG switch components with the is directive which is easy and reliable.
If we were to make everything into mixin, even the template would need to do be included in the mixin, and we would loose the nice layout of .vue files and make everything much more complex (bad linting, no syntax highlighting, no preprocessor).
I don't see that as impossible (if you find a way to switch mixins dynamically and face many new challenges), but given the current development of the plugin it would be too much work for almost no gain.
It is way easier to just update your custom field once in a while to add the latest and greatest feature.

This is only my view on the issue, maybe @icebob has another point of view.

[Vacilando]

I wonder, @icebob, do you have another point of view on this? It would of course be better to be able to extend rather than copying and adapting the source.

[cristijora]

@Vacilando
If you're using pug you can actually do that via Vue.extends and extend templates
http://vuejsdevelopers.com/2017/06/11/vue-js-extending-components/
If not you can extend the component only and copy the template part from the original vfgField and modify it how you want

[icebob]

Yes, it would be good, but in current implementation it is not possible.

[lionel-bijaoui]

That would be nice, but shouldn't we do something like "VFG engine" and make all fields separate modules.
That would split the issue to each individual fields repo.
I'm talking, no core fields, no optional fields. Something like Babel, Grunt, etc. has done.
That way we could just use the fields we need and nothing else.
For example, right now, I need VueMultiSelect, but I don't care about all the other optional fields. So I'm forced to copy this fields.
You just npm i -S vfg-field-myfield and import it and use it.
This should be evaluated for the v3, I'm convince this is the best solution.

[cristijora]

Maybe simpler alternatives such as adding component names exporting fields in a separate file
//input field

export default{
name:'vfgFieldInput'
}

//fields index file

export default {Input, Checkbox} etc 

install(Vue,options) {
     Vue.component("VueFormGenerator", module.exports.component);
     if(option.fields){
       fields.forEach((field)=>{
         Vue.component(field.name,field);
       })
     }
}

Usage:

import VFG from 'vue-form-generator'
import {Input, Checkbox, AutoComplete} from 'vue-form-generator/fields'
Vue.use(VFG, [Input,Checkbox,Autocomplete])

To me this seems more usable and controllable (in terms of size because webpack does tree-shaking if you do partial imports) rather than installing a new field with npm. Npm packages as fields might be a good idea for direct script includes if you don't need the whole vfg

[random-one]

@cristijora yes, that was it what I needed. To import a single field and then do whatever I want with it. It's more like project structuring work than implementation of engines and stuff.

[cristijora]

I think you can already do that @random-one by importing it then registering it on vfg directly but what I wrote above would be prettier, cleaner and more straight forward. The disadvantage here is that users will have to import pug if the field implementation is kept as it is

[random-one]

@cristijora I agree with you that your proposal is better and more straight forward. I couldn't do what you suggested because I'm too new to vue.js and couldn't dug them out of the module.

[lionel-bijaoui]

@cristijora I like your idea a lot. Could we do that as well ?

import VFG from 'vue-form-generator'
import {Input, Checkbox, AutoComplete} from 'vue-form-generator/fields'
import myField from 'custom/myField'
Vue.use(VFG, [Input,Checkbox,Autocomplete, myField])

[cristijora]

Yes of course. That's the whole purpose of it to register components. Inside the install method it simply
Vue.component(component.name,component) registers the component globally. The only condition here is for the component to have the correct naming format (vfgFieldWhatever.... I think we can make a check there and provide some error if the name is missing) and extend the abstractField which is already a condition

[lionel-bijaoui]

@icebob Is it too late to implement this solution ? I know you wanted to release v2 this week.

[cristijora]

Hm I already got stuck on this due to some tests issues. Even if I delete the components registration from vueFormGenerator.vue the tests still pass. @icebob any idea ?

[icebob]

@lionel-bijaoui I don't understand how it will solve the original problem?
@cristijora I have no idea, I will check it.

[lionel-bijaoui]

@icebob It doesn't but it make VFG more modular and this is something I convinced is needed (#67 was a first step). The app I'm building is big so we need to trim as much fat as possible.
@cristijora solution is a good middle ground between "packs" and "ultra modular". Since it will require breaking the current API, it need to come with a new major version. So either we do it now and made that feature available for the v2, or we wait until v3.

[icebob]

I think it needs more time & development, so it comes only in the next major v3.
And please create a new separated ticket, because it is not refer to this ticket.

I created label & milestone for v3