Custom Form Components: FormEngine vs Formik vs RJSF vs SurveyJS [2026]

​

Why custom components matter

1. How many concepts you have to learn before your component works end-to-end (registration, data binding, validation, events).
2. Whether the component is serializable — can a JSON schema reference it, or is it tied to JSX?
3. Whether a visual editor can use it — or is your custom component invisible to non-developers on the team?

​

Side-by-side: registering a custom input

​

FormEngine

import { define, event, string } from '@react-form-builder/core'

const MyInput = ({ value, onChange }) => (
  <input value={value ?? ''} onChange={e => onChange(e.target.value)} />
)

export const myInput = define(MyInput, 'MyInput')
  .props({
    value: string.valued,
    onChange: event
  })
  .build()

​

Formik

import { useField } from 'formik'

export const MyInput = ({ label, ...props }) => {
  const [field, meta] = useField(props)
  return (
    <>
      {label && <label htmlFor={props.id || props.name}>{label}</label>}
      <input {...field} {...props} />
      {meta.touched && meta.error ? <div className="error">{meta.error}</div> : null}
    </>
  )
}

// Usage — must be inside <Formik> provider:
// <MyInput name="email" label="Email" />

​

react-jsonschema-form (RJSF)

import Form from '@rjsf/core'
import validator from '@rjsf/validator-ajv8'

const MyInput = (props) => (
  <input
    type="text"
    value={props.value ?? ''}
    required={props.required}
    onChange={e => props.onChange(e.target.value)}
  />
)

const widgets = { myInput: MyInput }

const schema = {
  type: 'object',
  properties: { email: { type: 'string' } }
}
const uiSchema = {
  email: { 'ui:widget': 'myInput' }
}

<Form schema={schema} uiSchema={uiSchema} widgets={widgets} validator={validator} />

​

SurveyJS

import { ElementFactory, Question, Serializer } from 'survey-core'
import { ReactQuestionFactory, SurveyQuestionElementBase } from 'survey-react-ui'

const CUSTOM_TYPE = 'my-input'

class QuestionMyInputModel extends Question {
  getType() { return CUSTOM_TYPE }
}

Serializer.addClass(
  CUSTOM_TYPE,
  [],
  () => new QuestionMyInputModel(''),
  'question'
)

ElementFactory.Instance.registerElement(CUSTOM_TYPE, (name) => {
  return new QuestionMyInputModel(name)
})

class SurveyQuestionMyInput extends SurveyQuestionElementBase {
  get question() { return this.questionBase }
  renderElement() {
    return (
      <input
        value={this.question.value ?? ''}
        onChange={e => this.question.value = e.target.value}
      />
    )
  }
}

ReactQuestionFactory.Instance.registerQuestion(CUSTOM_TYPE, (props) => {
  return React.createElement(SurveyQuestionMyInput, props)
})

​

API surface at a glance

​

Lines of code to production-ready

• FormEngine: ~10 lines (React function + define().props().build()).
• Formik: ~15 lines of JSX — but not JSON-addressable, so it doesn’t reach feature parity.
• RJSF: ~20 lines plus you carry a second schema (uiSchema) alongside your data schema everywhere the form is referenced.
• SurveyJS: ~40 lines across model class, serializer call, two factory registrations, and a React wrapper class — before you’ve wired up properties or validation.

​

Portability: the argument that gets forwarded to your architect

• FormEngine. A custom component is a named entry in the view. Any JSON schema that references "type": "MyInput" renders correctly in any app that includes myInput.model in its view. The same schema works in the runtime and in the Designer — no parallel uiSchema, no widget ID translation.
• RJSF. Schema and uiSchema are two artifacts. To use the schema elsewhere you must also ship the uiSchema and the widgets registry that matches the widget names uiSchema references. If the widget names change between apps, schemas break silently.
• SurveyJS. JSON survey definitions reference your custom question by type string. The receiving app must register the same model class, serializer class, and React question class before it can render. Portability works, but the receiving app imports code, not just JSON.

​

What this means for adoption

• Less ceremony per component. One function, one chain, done. Useful when you have ten custom fields, not one.
• Components don’t fragment your team. Designers/PMs can edit forms in Designer, developers can edit forms in JSON, and both are looking at the same custom component registry. You don’t need to rebuild the form twice.
• MIT runtime. The free Core package renders your custom components in production at zero cost. Designer is optional and only needed when non-developers should edit the forms visually.

• Formik’s useField is genuinely minimal if you never need JSON schemas or a visual editor. For a single internal form, it’s fine. The cost shows up when the same form has to live in three places.
• RJSF is the right answer if you are strictly bound to the JSON Schema standard for data validation and interop with non-React consumers. FormEngine uses its own UI schema, which is richer for form concerns but not a JSON Schema drop-in.
• SurveyJS is the right answer if the product is literally a survey platform — scoring, respondent tracking, multi-page question logic. The heavier custom-component API is the price of the richer survey model.

​

Next steps

• Build your first FormEngine custom component in about 10 minutes: Custom Components guide.
• See what a valued (data-bound) custom component looks like with validation: Valued Components.
• Compare FormEngine against specific competitors head-to-head: FormEngine vs Formik, FormEngine vs RJSF, FormEngine vs SurveyJS.
• Check the bundle-size trade-offs for each runtime: Bundle size comparison.