A Semantic Strictly Typed React.js Forms Builder: Syntax

💩 CRUDdy Forms

💤 RESTfulness

🧠 Theory of a Form System

✨ Abstraction

  1. Map a resource to a bunch of fields (like age would be a number field)
  2. Map those fields to a layout
  3. Generate a form: fields + layout + values = Form
  4. Collect inputs
  5. Send back the result back to the server

🗺 Mappings

⚛ React is Pretty Powerful

Takeaways

  1. Resulting syntax is super easy to scan through.
  2. All fields have a standard interface
  3. Layout is abstracted away from the fields (allowing multiple layouts)
  4. No hooking up fields to change handlers
  5. No code to render fields/layout
  6. Memoization/performance can be managed by <Form />

💻 Codifying a Design System

  1. Rules for consistent components
  2. Protocols to keep them interoperable

Coding Benefits

  1. Consistent interfacing protocols (how existing and new components connect with one another) reinforced using types
  2. Lock down UI/UX rules like spacing with named space options like 'small' or 'medium' rather than using numbers
  3. Pipeline: we can define a core library of components that you can reference using a keyword like text or checkbox but also support custom components that can eventually be added into the system after vetting

UI/UX Benefits/Patterns

  1. Spacing is consistent but overridable with named widths:
    'small', 'medium', 'large', etc.
  2. Labels and headers are consistent
  3. Fields look consistent

🚫 Disabled

<Form
fields={fields}
layout={layout}
value={value}
setValue={setValue}
disabled
/>

📖 Readonly

Readonly

<Form
fields={fields}
layout={layout}
value={value}
setValue={setValue}
readonly
/>

⚖ Balancing Rigidity and Flexibility

📰 Multiple Columns:

🔗 Combined Fields:

Anonymous Display Fields:

📱 Responsive Layouts

WYSIWYG

🐛 Known Issues

The Code

🟦⚛ TypeScript + React is Amazing

  • The value should be compatible with the fields
  • The layout should refer back to the existing fields
  • etc.

Defining the Relationships in <Form />:

  • The field names inside the fields object must match the keys inside the resource
  • Each field component supports some types like number or string, these must work with the resource, for example, if birthday is a Date then we should be using a type: 'date' field
  • The definition for options inside fields holds the props for a field component, it must be compatible with that component. For example, you can’t give a 'counter' type field, a maxLength prop
  • We can check if the fields being referenced in the layout refer back to the keys in the fields

Part 2 coming in a bit

--

--

Power using Typescript https://www.linkedin.com/in/steven-l-ab0a6a77/ https://github.com/whalemade

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store