+
Skip to content

re-introduce custom signup forms [3] #629

@aguestuser

Description

@aguestuser

[stub]

Context

  • realized while blocked playing 2-step email signup path [3] #613 that cusom forms are heavy and we don't actually need them yet, so we ditched them until we do
  • by "heavy" i mean: it is difficult to introduce non-text fields into the schema (like passwords and dropdowns) and difficult to run migrations from the schema that worked for just text fields
  • when groups start asking for different fields in their signup forms or multiple signup forms that allow them to track the source for new signups, then play this

Implementation Notes

  • currently we store a FormInputGroup that has a string field for inputs and required which is stored in postgres as an array (ie: :inputs, :string, array: true, default: [] settings in the original migration)
  • we could changes this to :inputs, :text, default: '[]', but is requires non-trivial backfills and breaks rollbacks
  • instead, i think we should ditch the inputs and required fields altogether and instead introduce a has_many-belongs-to relationship between FormInputGroup and a new class called FormInputGroup
  • where FormInputGroup has the fields type (an enum with possible values: text, textarea, select, password, etc.), attr_name (for the attribute the form field will create), label (for the form label), and, optionally options (if it is a select).
  • this will allow cleaner logic for aliasing and recongizing required fields and will generally be cleaner than trying to do it with hashes
  • it will require slightly rewriting SignupForm.for

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载