V3 plans

[icebob]

Plans:

• [x] Better grouping #259
• [ ] Customizable element classes #274
• [x] Customizable layout
• [x] Better validation
• [x] Webpack 3 #349 (in progress)
• [ ] Official site with better documentation & examples (Docsify)
• [ ] Better modularization
• [x] Better field options
• [ ] Support I18N #352
• [ ] Dynamic fields #226
• [ ] ...etc

Any new idea?

Ping @lionel-bijaoui @cristijora @dflock @zoul0813

Branch: https://github.com/icebob/vue-form-generator/tree/v3

[murilolopes]

I'm having a bit of trouble getting the generator to run, I can, but I'm having to dig a little to figure things out. I think one point would be a documentation with more practical examples mainly in regards to changing layouts / style.

I do not know if it already exists, but another point would also be valid for laravel or something. I think that through an eloquent model with some extra attributes we can generate form through api requests

[lionel-bijaoui]

1. I really wish to make a stripped down "engine" version, along with "core" and "full". I realized that in my project, I have to redo most of the basic fields, since I need to add thing to fit my project's specific needs.
   I don't have an exact solution, but anything that allow to pick and choose exactly what I need and nothing more would be nice

2. Change the syntax to be more strict. I mean, only these options are available in the top level of all fields, and any other field specific option must be in fieldOptions. That mean rewriting a lot of stuff, but we can be more clever with abstract field.

   // from this
   {
   type: "checklist",
   label: "Ingredient",
   model: "ingredient",
   values: [
       { uuid: "a11e3f4b-d4f1-45ed-87fc-4eabda4e667e", name: "Cherimoya"},
       { uuid: "5ceb59c6-efe6-4c8a-a4bd-0ef621cd1e5d", name: "Pummelo"},
       { uuid: "39f05038-39ba-4cb9-8508-720806dcb20b", name: "Jabuticaba"},
       { uuid: "94adbe8d-f9db-481c-97c0-7198d5f3d810", name: "Kiwano melon"}
   ],
   listBox: true,
   checklistOptions: {
       value: "uuid" 
   }
   }
   // to this
   {
   type: "checklist",
   label: "Ingredient",
   model: "ingredient",
   values: [
       { uuid: "a11e3f4b-d4f1-45ed-87fc-4eabda4e667e", name: "Cherimoya"},
       { uuid: "5ceb59c6-efe6-4c8a-a4bd-0ef621cd1e5d", name: "Pummelo"},
       { uuid: "39f05038-39ba-4cb9-8508-720806dcb20b", name: "Jabuticaba"},
       { uuid: "94adbe8d-f9db-481c-97c0-7198d5f3d810", name: "Kiwano melon"}
   ],
   fieldOptions: {
       listBox: true,
       value: "uuid" 
   }
   }

[cristijora]

Agree with @murilolopes Usually docs with many examples are beneficial both for users and for maintainers because when you write examples and use it yourself you might find that something is needed missing. I have been digging around different ways to build good docs lately. There are a couple of alternatives:

• Storybook (Good overall but has some limitations regarding UI look and feel and custom organization)
• Docsify + some plugins (Good and easy. Markdown based. The UI looks ok and can be customized a bit)
• Custom solution with markdown loaders (Most flexible but requires more effort)

Here are some examples for:

• Docsify - You basically write the code in markdown and it gets rendered both as code sample and html + you can add the option to render it in a jsfiddle
  • Storybook The setup here is kind of heavy and there is much boilerplate.

I could build up something based on docsify quickly.

[icebob]

Docsify +1

[lionel-bijaoui]

@cristijora @icebob I like the control (knobs) you can add in storybook. Storybook seem more popular too. I would vouch for it. Edit: Docsify is nice though...

[cristijora]

Yes @lionel-bijaoui but from experience I found it harder to maintain mainly due to a lot of abstractions and boilerplate code. Markdown is easier to write usually and personally I would go for a custom solution with markdown loaders or docsify

There are also other options like Vue styleguidist but never tried it

[lionel-bijaoui]

@cristijora Yeah, I don't have hard feeling for that. Plus, you have experience with it so you can teach us and help make it better :)

[cristijora]

Regarding other issues, struggles I personally had when using vfg I can say that, I found myself as @lionel-bijaoui stated writing many "custom fields" which were basically wrappers around the original fields. I feel like there should be some sort of a wrapper field in the layout just like element-ui has http://element.eleme.io/#/en-US/component/form

Generically speaking it could be something like

 <div>
   <label>
   {{label from props}}
   </label>
   <slot></slot>
</div>

Just like form-group class wrapper from bootstrap and it will contain the abstractMixin. According to some rules like it should work with v-model we would simply chose what goes into that slot without writing a new custom component

 type: "input",
 component: "el-input"
 component-props: {
  min-length: 3,
  size: "lg"
 },
 label: "ID",
 model: "id",
 readonly: true,
 featured: false,
 disabled: true

And these component-props can be bound with inheritAttrs for example.

That's a very distant idea I guess. Maybe a small example first would be nice

[lionel-bijaoui]

@cristijora the 2.4.0 brought a lot of new interesting possibilities to Vue. Maybe we can tap into inheritAttrs and $attrs ? I have a hard time wrapping my head around that, but it seem promising.

[zoul0813]

I can probably work on the "Better Grouping" and "Customizable layout" as I'd like to have support for this in my current project and was planning to introduce some changes in my personal fork this week and next.

I was planning to introduce a "formGroup" component and move some of the logic out of "formGenerator" into "formGroup". The new formGroup would work similar to how existing control components work, but would allow for nested groups. This would help with building wizard/tabbed UI's for example, and open up possibilities for some fairly advanced form structures.

I did something similar to this in another project, where I built a form generator like VFG for AngularJS. Each group was capable of tracking it's own validation status, triggering validation within the group, etc ... almost as if each group was a separate VFG instance, but all contained within a single VFG instance with a single schema.

[cristijora]

@icebob How can I access the files from the gitbook docs? Are they written in markdown?

[lionel-bijaoui]

@cristijora I just saw this pop up in the Vue newsletter. Look promising, what are your thoughts?

[icebob]

@cristijora I added you to gitbook repo. Yes, the docs is written in markdown

[icebob]

Guys, I feel that in the future I have no enough time to lead the whole VFG project. In V3 I see we will have to rewrite the whole components and docs. I don't want to be a bottle-neck. So I'm thinking on that I will create an organization for VFG and add you as same members. What do you think?

[cristijora]

Personally I think that's a good idea

[zoul0813]

I’m good with that.

[icebob]

Any idea for organization name?

[cristijora]

ice-vue vue-form-generator vfg easy-forms

[DelfsEngineering]

Why does the name need to be different? Team VFG is fine.

[DelfsEngineering]

I see VFG as much more than forms. I have made many custom components and use VFG as a dynamic page render. I create pages much like word press makes pages dynamicall. Super powerful. This can become the core engine to similar applications.

[icebob]

I plan to create other Vue generators in the future. For example:

• vue-table-generator. A schema-based table generator. Example component and schema
• vue-page-generator. A schema-based admin page generator using the vue-table-generator & vue-form-generator. Example page code

So the organization could be vue-generators.

[rafaesc]

Hello there!

If you need document the library, I suggest vue-styleguidist, you can see these examples:

http://rafaelescala.com/vue-styleguide/ https://croudsupport.github.io/Croud-Style-Guide/technical/ https://vueds.com/ http://rafaelescala.com/buefy-example/ http://rafaelescala.com/vue-konva-doc/

It's possible to document props, methods, events, and slots. Vue-styleguidist give you a living style guide and it allows you a custom the theme and style. If you need help you can tell me, because I am developing this generator.

[icebob]

Organization created: https://github.com/vue-generators

[zoul0813]

Not sure if anyone else has worked on this, but I created a branch in my fork and started working on updating VFG to the latest version of Vue (2.5.9), along with various other packages such as Pug, Karma, Mocha, and a few other packages.

So far, the branch is fully functional, and only the "should become a color" test is failing in fieldInput.spec (currently, I set it to skip the optional fields as I personally believe these should be included as additional packages as needed, due to the number of dependencies required for them all and to allow for more extensive testing and examples for these specialized fields).

[icebob]

Great news. If you think, send a PR to the v3 branch.

[zoul0813]

Will do, probably later this week though

[lionel-bijaoui]

@zoul0813 I was doing that #349 😞

[zoul0813]

@lionel-bijaoui sorry, I needed a newer version of Vue for a project I’m working on ... all I did was update the package versions on Vue and some of the test related packages. I also updated some tests and code due to the updates. Don’t believe I modified or updated webpack or the build configuration.

I’m actively working on a project that relies on VFG, so most of my contributions are related to moving forward with that project which is time sensitive.

[lionel-bijaoui]

No problem, I'm really busy at work and I did not give update for more than a week. I have updated my work, and I will do a PR. There are big changes and many bugs to fix.

Edit: #357

[zoul0813]

Sounds good - we can together on it maybe? I’d also like to propose removing the optional fields from VFG, and separating them out into their own packages ... so we can test and support them a bit better, and cleanup what’s in the core package.

[zoul0813]

Just a thought, but anyone working on v3 updates should make sure they keep their updates in sync with bug fixes and new features added to v2 master ... this way we don't fix bugs in v2 and carry them over into v3.

[vesper8]

am really looking forward to v3 with support for slots and documentation on how to use slots to achieve custom layouts

currently trying to do something as simple as having the label and field inline is a bit of a mystery.. lots of occurrences of "slot" when searching issues but no clear example of how to achieve it

I think V3 is going to be great though judging by the list in the first post of this thread. Do you think it will be ready by the end of January?

[zoul0813]

I've started working on enhancing VFG's support for grouped fields. I wanted to have the ability to nest my groups, to help with more advanced layouts (a bootstrap btn-toolbar group, with multiple btn-group's each containing buttons) without needing to resort to custom components.

What I've got so far is sitting in my forks v3-features/styling branch ( https://github.com/zoul0813/vue-form-generator/tree/v3-features/styling ).

I moved the bulk majority of the logic in formGenerator's template into a new formGroup and formField component, which allows formGroup to nest itself, and formField takes over the '.form-group' wrapper logic that was in formGenerator. This will also allow formGroups to report validation status for fields contained within them. I'm going to replace the existing this.$children loops for validation with logic that registers groups and/or fields with it's parent, this way we don't loop through groups to trigger individual field validations, and we can skip over "non field" components (such as custom components designed to assist with layout, like a clearfix component, tab component, etc).

I also started standardizing some of the layout properties, using things like 'label', 'labelCssClass', 'labelTag', etc. These all have defaults which match the existing v2 layout, but allow the form creator to override them ... for example, the "legend" in a group can be a <div class="panel-heading">{{ label }}</div> tag, instead of a fieldset legend tag.

I'm open to ideas on this approach, and welcome any feedback.

[icebob]

It sounds good.

[zoul0813]

I should have a sample available after the holidays. I’m on vacation for three weeks, so probably won’t be touching much Code

[donalmurtagh]

Support for dynamic fields would be really useful #270 #226. Without this feature, there is no obvious way to collect a list of values/objects if the length of the list is indeterminate

1. Simple Arrays

For example, a form that allows the user to upload an unlimited number of images, each image would be stored base64 encoded inside an array.

2. Arrays of Objects

For example, if a user needs to enter the name, surname and date-of-birth of each of their children, this would be stored in the model as:

[
  {"name": "John", "surname": "Doe", "dob": "1999-01-01"},
  {"name": "Jane", "surname": "Doe", "dob" "2000-01-01"}
]

A suggested implementation is to add [+] and [-] buttons to the form which would allow the user to add and remove an item in the array. In the case of (2), clicking these buttons would add/remove a group of fields.

Support for this feature exists in Angular Schema Form (an AngularJS declarative form library). The feature is documented here and a demo is available here by choosing "Array" from the "Select Example" dropdown.

[vesper8]

Any update on the progress for V3? Not being able to use scoped slots and have full control on the html wrapping the input fields is really preventing me from adopting this library more completely in my projects.. would you say that you plan to release slot support soon? many thanks

[jaywilburn]

IDEA: What about a built-in dynamic fields based on the user's selection, similar to this: http://appliedmathematicsanu.github.io/plexus-form/ On the demo, when you select yes on the favorite color, it will then expose a new field (dropdown) to make a new selection. If this is built in already please forgive me (and please point me in the direction to this) but I thought many users could benefit from it.

[exnihilo-creatio]

@icebob This might be thought as another project for the VueGenerators organization. How about a GUI for building schema's that generates the schema which can be saved in a database.

[icebob]

Hi @lionel-bijaoui @cristijora @dflock @zoul0813, I created a @vue-form-generator organization on NPM. If you send me your NPM username I will add you as members.

I think we can publish VFG v3 modules under this org. E.g.

@vue-form-generator/core
@vue-form-generator/full
@vue-form-generator/slider
@vue-form-generator/date-picker

...etc.

What do you think?

[zoul0813]

@icebob my npmjs.com user is zoul0813

[JoshuaJarman]

I know I'm coming late to the discussion, but I'm really hoping that the next version will have support for passing a custom attribute/property array to any form element to set additional attributes/properties.

This is such a core piece of html5 plumbing and building components in general. This open design pattern enables maximum usage flexibility.

This is crucial to integrating with other frameworks and libraries and components. It is how vue itslef works...vue itself leverages its own custom attributes for all its binding and goodness, we want the power to use the same wiring most the modern web does via attributes. 👍

Ideally i'd like to see something like the alternative vue-form-schema vue component does, where they simply pass any additional attributes in. This doesn't seem like it would be difficult, right? Should be an easy ask?

passing in this:

"attrs": {
     "toggle": "true",
     "title": "This is the title",
     "custom": "A custom attribute",
     "verify": "regex",
     "whatever": "this is a crucial ability, right?"
}

results in: <input toggle="true" title="This is the title" custom="A custom attribute" verify="regex" whatever="this is a crucial ability, right?" />

I like this project's overall approach better than vue-form-schema but we will need custom attributes support if we are going to be able to use this in our specific project. Seems like something everyone would benefit from. Does that make sense? Am I missing something and this exists already? Thoughts?

Thanks!

[zoul0813]

@JoshuaJarman the latest PR for V3 adds exactly this functionality. The idea, for now, is that you're field schema can contain an "attributes" property, which is then broken up into "wrapper", "input" and "label" objects which contain additional attributes that are set on the input.

{
  type: "input",
  inputType: "text",
  model: "first_name",
  label: "First Name",
  attributes: {
    wrapper: { "data-toggle": "collapse" },
    input: { "data-toggle": "tooltip", "title": "Some Tooltip to be displayed by Bootstrap Tooltips" },
    label: { "custom-attr": "custom-value" }
  }
}

If you do not specify where the attributes go, and just provide a flat "attributes" property ( { "data-toggle": "collapse", "data-toggle": "tooltip", "title": "Some Tooltip Title" } ) then the attributes will be assigned to the "input" element on the component.

It's a WIP at the moment, and is subject to change ... but the PR is currently being reviewed and will hopefully be merged into the v3 branch soon.

[slathrop]

Would someone kindly add me to the docs and/or org so that I can contribute back to this codebase and documentation please? I'm starting a pretty large project and plan to use/extend VFG. Thanks!

[dflock]

@icebob Sounds like a good plan. My npm username is dflock.

[slathrop]

@icebob my npmjs.com user is SLathrop. Thanks.

[jivansupe]

Hello Everyone, Read the comments on the attributes thing. Just curious to know if the attributes functionality is implemented or yet to be updated? Wanted to have this feature in in my project. Please do update. Thanks 👍

[zoul0813]

@jivansupe this is available in v2

[goatandsheep]

@zoul0813 the attributes object works for me in v2.3.4

[zoul0813]

@goatandsheep - ok?