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.