chore(deps): bump minimist from 1.2.5 to 1.2.6

[dependabot[bot]]

trafficstars

Bumps minimist from 1.2.5 to 1.2.6.

Commits

• 7efb22a 1.2.6
• ef88b93 security notice for additional prototype pollution issue
• c2b9819 isConstructorOrProto adapted from PR
• bc8ecee test from prototype pollution PR
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

[ismail-codar]

Address entry with two different ways. 1- City, district, neighborhood selection and door number entry. (Address textfield is disabled and value of address is calculated from selectboxes) 2- Free-text address entry (Address textfield is enabled and City, district, neighborhood, door number fields are hidden)

[ismail-codar]

If "Is Active" is checked, the "Password Expiration Date" field will be displayed and the entry will be required. Otherwise, the "Password Expiration Date" field must be hidden.

[ismail-codar]

Form UI (html and css) must be pre defined in advance. All implementations should use it. UI Features: 1- Mandatory fields must be indicated by (*) 2- In the wrong entries, the .error css-class is added on the field. (with live validation) 3- Inline error message is putted below the field.

[muratcorlu]

Address entry with two different ways. 1- City, district, neighborhood selection and door number entry. (Address textfield is disabled and value of address is calculated from selectboxes) 2- Free-text address entry (Address textfield is enabled and City, district, neighborhood, door number fields are hidden)

City, district, neighborhood selection needs a bit more complicated backend support. Also doesn't add a specific feature for comparison. Couldn't be sure about that.

[muratcorlu]

If "Is Active" is checked, the "Password Expiration Date" field will be displayed and the entry will be required. Otherwise, the "Password Expiration Date" field must be hidden.

Having a date/time field can be a good idea to compare date validation approaches.

[muratcorlu]

Form UI (html and css) must be pre defined in advance. All implementations should use it. UI Features: 1- Mandatory fields must be indicated by (*) 2- In the wrong entries, the .error css-class is added on the field. (with live validation) 3- Inline error message is putted below the field.

Giving a starter HTML/CSS page could be helpful for excluding UI design part from comparison. But forcing people to use this HTML/CSS only doesn't look like a good idea. Maybe some people will want to use custom components with different HTML structure.

[ismail-codar]

Address entry with two different ways. 1- City, district, neighborhood selection and door number entry. (Address textfield is disabled and value of address is calculated from selectboxes) 2- Free-text address entry (Address textfield is enabled and City, district, neighborhood, door number fields are hidden)

City, district, neighborhood selection needs a bit more complicated backend support. Also doesn't add a specific feature for comparison. Couldn't be sure about that.

Browser side mock server can be a solution for backend api.

My intention is form logic should not be simple and can have these features. Needed unnecessary ones can be discussed

• Programmatically loading data into select lists (combo, radibuttons etc). A cascading data example
• Conditionally show hide or enable disable fields if required. (example)
• Live validation with oninput, onblur events or validation on form post.
• Form data edit mode, reset form to default values, readonly mode.
• Hidden fields.
• File or file list upload. Also inline display for selected file.
• Sub form or input lists.
• ...

[burakcan]

I think the examples shouldn't be using any third party libraries besides the fw itself. This way it'd be easier to see and compare differences.

[muratcorlu]

AFAIK, Vue and React doesn't give a special solution for form validation. But many developers of them prefers to use some plugins. I think it would be good to show all options, including core library solutions.

[burakcan]

So maybe having them under seperate entries could be an option. Like: "React, React-xlib, React-ylib"

[muratcorlu]

Indeed. My idea was having separate examples for different approaches or extensions.

[ismail-codar]

Angular ngx-formly, react-final-form, formik or vue-final-form... Third party components can be used for form validation, form state management etc..

My opinion is that the frameworks-libs-infrastructure can be different but the form behavior and user interface should be the same for all implementations. It like TodoMVC. My suggestion: Pre-define form UI with bulma or with bootstrap form controls. Also standardize form behavior. Only third party UI libraries should not be used.

Also another idea is a standardized form behavior but user interface can be freely different.

[muratcorlu]

Then let's create a form with just html and css as a reference. Then everyone can do their own versions. I'll try to create that reference form.