Extract and set form values through the DOM—no frameworks required! https://github.com/TheoryOfNekomata/formxtra
Вы не можете выбрать более 25 тем Темы должны начинаться с буквы или цифры, могут содержать дефисы(-) и должны содержать не более 35 символов.

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758
  1. # Rationale
  2. **Why the need for another form library?**
  3. Let us set some facts about existing form libraries:
  4. * Form libraries, especially framework-specific ones have verbose syntax.
  5. * Please go to your form library of choice and compare the syntax yourself.
  6. * Form libraries are dependent on the architecture of the framework (such as [React Hook Form](https://www.npmjs.com/package/react-hook-form) and [Formik](https://www.npmjs.com/package/formik)) and
  7. requires using their features.
  8. * Form libraries have differing ways on how to manage state, usually piggybacking on the data flow of the framework they
  9. are dependent on.
  10. * Form libraries are relatively complex to what they are supposed to be doing such as providing wrappers to custom
  11. components, in which compatibility should be in the hands of the component author.
  12. **What does `formxtra` offer?**
  13. * `formxtra` aims to simplify the syntax to just invoking two functions - `getFormValues()` and `setFormValues()`.
  14. * `formxtra` is not dependent to any library and is highly interoperable.
  15. * `formxtra` is dependent only to the DOM. Since accessing the DOM is fully synchronous, the same can be said for the
  16. entire operation of `formxtra`.
  17. * There are no other paradigms introduced by `formxtra`. For the library to do its intentions, it only requires
  18. respecting the HTML DOM spec, such as providing names to inputs and binding them correctly to forms, which is what
  19. all (data-driven) websites should do anyway.
  20. * `formxtra` is lightweight, even smaller than [React Hook Form](https://www.npmjs.com/package/react-hook-form) and [Formik](https://www.npmjs.com/package/formik).
  21. * `formxtra` is already type-safe, being written in TypeScript and providing types, thanks to [pridepack](https://www.npmjs.com/package/pridepack) as a scaffold.
  22. **What does `formxtra` not offer?**
  23. * `formxtra` is not a validation library, nor does it provide utility functions for validation.
  24. * However, one could use `formxtra` in tandem with other validation libraries
  25. such as `ajv` or `yup` for instance, by validating the values returned by `getFormValues()`.
  26. * `formxtra` does not provide compatibility to custom components.
  27. * Because custom components have different
  28. implementations that mostly favor user experience over compliance, `formxtra` does not guarantee it can work with them
  29. out of the box.
  30. * However, the solution for this is to provide a corresponding `<input type="hidden">` element for each custom\
  31. component, which should always get the latter's serializable value. In return, this can also simplify the submission
  32. of the form as the custom components' values are already in the form.
  33. Forms are used to package related data, typically sent to an external location or processed internally. In the browser,
  34. the default behavior of submitting form data is not always preferred, as this is done through loading or reloading a
  35. document as soon as the form is submitted. In addition, [applications have limited control over how the data are
  36. formatted on submission](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-fs-enctype) with
  37. this approach. This is why the new way of sending form data is done through AJAX/fetch requests, wherein the data are
  38. serialized into formats like JSON. To turn form data into a specific format requires access to the elements holding the
  39. values to each field in the form.
  40. Libraries made for extracting form values query field elements in the DOM, which is inefficient since they need to
  41. traverse the DOM tree in some way, using methods such as `document.getElementsByTagName()` and
  42. `document.querySelector()`. This is the same case with setting each form values for, say, prefilling values to save
  43. time. It might be a simple improvement to the user experience, but the logic behind can be unwieldy as there may be
  44. inconsistencies in setting up each field value depending on the form library being used.
  45. Upon retrieving the field values somehow, some libraries attempt to duplicate the values of the fields as they change,
  46. for instance by attaching event listeners and storing the new values into some internal object or map. This is then
  47. retrieved by some other exposed function or mechanism within that library. This is common with reactive frameworks,
  48. where changes to the document are essential to establish functionality and improved user experience.