Update to Webpack 3. Almost all dependency are updated. #357
Conversation
…nced-validate-fix fixes vue-generators#345 - declare debouncedValidateFunc
…n of the config files. Now use Prettier, so most files are will need to be updated to validate. This is stil an early WIP. Known bugs: validation is broken since rewritten in without "module.exports"
|
|
Will review tomorrow morning |
|
I'm not sure if I'm comfortable with merging this in, as it's currently in an unusable state. The broken validators are a major issue, for example, as is the broken I like the direction you're heading in though. Perhaps we should have two branches for v3? One as a 'v3-master' and another as a 'v3-dev'. This way we can merge "broken" code in so everyone can contribute to fixing it, and another for "stable" v3 changes? |
|
This is not supposed to be ready to merge yet.
I want feedback from the collaborator on the direction I going with this. My biggest problem is my lack of time, since at work, we are very close to the big launch + Holidays coming. |
…rmatValueToModel` * Updated to fecha 2.3.2 * Moved the majority of logic from computed.value.set() to new `updateModelValue(newValue, oldValue)` method to allow other components to use similar techniques. If `formatValueToModel` returns a function, then the function is called without setting the model value. It is the functions responsibility to call `this.updateModelValue(newValue, oldValue)`. Otherwise, calls `this.updateModelValue(newValue, oldValue)` to execute the original logic. * If the input type is date, datetime, or datetime-local then it creates a debounced function for setting the value in fieldInput's mounted hook and then returns a function that calls this debounced function from `formatValueToModel` * Reduced the repeated code for date formatting by adding a DATETIME_FORMATS constant, and using that to get the "format" for fecha.parse()
…echa fixes vue-generators#341 - introduced debounce functionality into `formatValueToModel`
…/range inputs, debounce `formatValueToModel` for number/range, removed `formatValueToField` Number inputs now support `10e10` formats being typed in, and stores the evaluated value of `10e10` (`100000000000`) on the model. * moved debouncedFormatDateTime to abstractField and renamed to debounceFormatFunc * create a `debounceFormatFunc` for number/range inputs, as well as date/datetime/datetime-local * changed @input to use `onInput` handler which checks for number/range and uses $event.target.valueAsNumber per @YgamiLight * set value to NaN if !isNumber(value) (NOTE: NaN is represented as "null" in JSON though as JSON does not support NaN/Infinity) * set all `inputType` checks and uses to use `inputType.toLowerCase()`, recommend doing this for all fields * created DEBOUNCE_FORMAT_MS constants in inputField.vue, set to default of 1000 ... recommend turning this into a standard schema option for all fields * wrapped one-liner conditionals with `{}` (just looks cleaner)
…idator, and returns `invalidIntegerl: "The value is not an integer"` as well as any errors generated by `number`
* wrapped one-liner conditionals/loops with `{}` (looks cleaner)
* simplified some conditionals by merging `if(cond1) { if(cond2) { } }` into `if(cond1 && cond2) { }`
…ield checks for `isNil(value)` and returns `null`, none options are always disabled * updated tests to reflect "none is always disabled", could possibly be a selectOptions to allow users to select the "none" option to clear a previously selected value? * added formatValueToField and return `null` when `isNil(value)`
…umber-values fixes vue-generators#361
…into feature/362-integer-validator * 'master' of https://github.com/icebob/vue-form-generator: fixes vue-generators#361 - use $event.target.valueAsNumber for number/range inputs, debounce `formatValueToModel` for number/range, removed `formatValueToField` # Conflicts: # dist/vfg-core.js # dist/vfg.js
…er-validator fixes vue-generators#362
…into feature/340-select-none * 'master' of https://github.com/icebob/vue-form-generator: fixes vue-generators#362 - `integer` validator now calls `number` validator, and returns `invalidIntegerl: "The value is not an integer"` as well as any errors generated by `number` fixes vue-generators#361 - use $event.target.valueAsNumber for number/range inputs, debounce `formatValueToModel` for number/range, removed `formatValueToField` # Conflicts: # dist/vfg-core.js # dist/vfg.js
…validators * added `validateAsync` (default: false) form option * added `isAsync` parameter to FormGenerator.validate() * FormGenerator.validate() and AbstractField.validate() return Promise when `validateAsync` or `isAsync` is true * renamed `click` handler to `onClick` in FieldSubmit * added `onValidationError(model, schema, errors)` to FieldSubmit schema to handle validation errors * added async validator support for FieldSupport * changed `each` to `forEach` in various places, as "each" is an alias to "forEach" and "forEach" looks more explicit * removed call to Vue.util.hyphenate as this is no longer supported by Vue, replaced with equivalent `String.replace` expression * updated fieldSubmit.spec to add "valid form" and "invalid form" tests, valid forms will always call `onSubmit`, invalid forms will not call `onSubmit` (when validateBeforeSubmit = true) * various code clean up
…-validation fixes vue-generators#358 - support "validateBeforeSubmit" with async validators
|
@zoul0813 There is already vanilla js alternative and jQuery is optional. But I absolutely agree, all fields should be their own project. I'm doing my best to finish the test as far as I can go and merge. Then I think every collaborator will be able to help. Still a looooot of work toward this new version, this is exciting and frightening 😀 Thank you ! EDIT: I should also mention that I wasn't available last week, that's why I progressed so little for a full week. I should finish before the end of this week. At least that's my goal. |
|
Should this not be updated to webpack 4 instead of 3? |
|
@ChadTaljaardt This project started before the v4 was even announced. I feel like it will require a lot of changes and I'm not sure the plugin ecosystem is up to date already. |
|
I thought @icebob said splitting the optional fields out was a good idea - could be mistaken, lots of discussions going on. I was under the impression the new group organization was setup to help facilitate the split of the optional fields into different packages (as well as create more projects with similar goals). |
|
I may have misunderstood. You are right, this new organization is perfect for that. Maybe @icebob changed his mind ? I sure hope so ! |
Progress Update
|
|
@lionel-bijaoui well, if he hasn't ... maybe we can do a "best of both worlds" solution, and split the optional fields up into separate packages anyway ... then have two versions of VFG ... a VFG Lite and a VFG Full, where VFG Full just includes all the optional packages in it's package.json ... this would then allow us to have the stream lined separate packages for easier development and testing of advanced fields, as well as provide devs with a "lite" version and a "full" version ... you could then start with the "lite" version and add any extra optional fields you wish, or just use the "full" version and get everything with a single package dep. The "lite" version would just include basic form fields, anything that's part of the HTML5 standard (input, select, check, radio, buttons, hidden fields, etc). @icebob thoughts? |
|
@zoul0813 It is already like that, you've got the core or full version. But from experience, we need an "engine" version without any field at all. |
|
@lionel-bijaoui the difference in what I'm proposing is that if you enable "full" you get it all ... you can't selectively decide that you want to use the "core" and then add in 1-2 optional fields ... Splitting the optional fields up into there own packages would allow me to just |
|
Hi guys, sorry for late. Yes, I support to split optional modules to separated packages in v3. And as @zoul0813 said, we can create a "full" bundle, which install all optional modules as npm dependencies. |
|
@icebob I'm so happy to hear that ! Will it use git submodule or separate package ? |
|
I think separate npm packages in separate github repos under vue-generators org. |
|
I will try to set npm publishing on travis, so every team member will able to release new versions without me. (Nowadays I'm very busy, sorry) |
Progress UpdateI worked on the overhaul of code coverage. I'm hopping this will pass Travis. Only one file to do ! I'm seeing the light at the end of the tunnel
|
Progress UpdateI cleaned the files and remove obsolete function. I'm not going to do any more work on the test. My goal now is to make the build successful.
|
|
@icebob I don't know how to activate Codacy for this branch, but except for that, everything is ready for the merge on my side. |
|
@lionel-bijaoui Great job! Thank you! |
config/index.js
Outdated
| build: { | ||
| env: { NODE_ENV: "\"production\"" }, | ||
| index: path.resolve(__dirname, "../../api/src/Template/Layout/layout_a.ctp"), | ||
| assetsRoot: path.resolve(__dirname, "../../api/webroot/"), |
There was a problem hiding this comment.
oups sorry ! I based my work on an existing project. I will fix that ASAP
Reorganisation of the config files. Now use Prettier, so most files are will need to be updated to validate. This is stil an early WIP.
Known bugs: validation is broken since rewritten in without "module.exports"