Skip to main content

Overview

This documentation presents a set of libraries BedrockStreaming uses to handle dynamic forms generation for its customers:

Why would you use these libraries ?#

The idea of these libraries came from the variety of requests our customers had in terms of forms. Thus, we wanted to be able to generate any form by simply passing some config and a dictionary of inputs to go with. As we were eager to keep some control over the process, we went with react-hook-form which has great capabilities. Unfortunately we were missing some features that we had to implement ourselves.

  • Complex validation with multiple visuals feedback
  • Steps handling

Features#

Here is a list of features we are supporting βœ…

  • βœ… Form Generation
  • βœ… Asynchronous Custom Validation
  • βœ… Multi Steps Forms
  • βœ… Conditional Fields

Here is a list of features we will not support ❌

  • ❌ Form UI Components

Here is a list of features we will probably support :thinking:

  • 🚧 Conditional Steps

Why did we have to make it ?#

Our context and needs#

Bedrock provides turn-keys streaming platforms on different devices. A few years ago, we didn't have to maintain many forms for our existing AVOD platforms - mainly login and register ones - while our customers mostly shared the UX and UI of such forms. However, since we started addressing SVOD platforms and higher customization expectations, we realized we had to industrialize the way we were handling forms or we would end up writing custom code for every customer, which would dramatically impact our core delivery schedule.

We decided that we wanted to:

  • Use our design system and existing styled-components inputs (excluding form generation libraries providing UI or html output).
  • Describe our forms from serializable schemas (json), so such schema could be shared across front-ends regardless of the language or library used to built it and even come from a server response.
  • Use complex validation, keeping in mind we didn't want to increase our bundle size by using a dedicated validation library (like yup or joi).
  • Display as many visual hints as there are validation rules on a given input (not just one error message, each rule would show its completeness state).
  • Avoid using redux (in our opinion, inputs should be uncontrolled or handling their own state locally)
  • Use multi steps forms.
  • Write the less code as possible. Of course.

A case study, looking for the right library :male_detective:#

We made some research of this ideal lib that would handle both the form state and the inputs generation, but we didn't found it. Formik and react-hook-from were top shelf candidates but were missing the generation part whereas react-jsonschema-forms had the schema and form generation capabilities but was lacking async validation and ease in input customization.

Contributors#

This project follows the all-contributors specification.


Pierre Huyghe

πŸ“– πŸ’» πŸ’‘ 🚧 πŸ€”

Antoine Caron

πŸ“– πŸ’» πŸ’‘ 🚧 πŸ€”

Florent Dubost

πŸ“– πŸ’» πŸ’‘ 🚧 πŸ€”

renaudAmsellem

πŸ“– πŸ’» πŸ’‘ 🚧 πŸ€”

jcoquet

πŸ“– πŸ’» πŸ’‘ 🚧 πŸ€”

UltiXstorm

πŸ“– πŸ’» 🚧 πŸ€”

Alves MickaΓ«l

πŸ“– πŸ’» 🚧 πŸ€”

Nicolas Castejon

πŸ“– πŸ’» 🚧 πŸ€”

Maxime BOUNAAS-FERRET

πŸ“– πŸ’» πŸ’‘ 🚧 πŸ€”

Mehdi Kabab

πŸ“– πŸ’» πŸ’‘ 🚧 πŸ€”

πŸ“ Licence#

Copyright Β© 2022 BedrockStreaming.
This project is MIT licensed.


This README was generated with ❀️ by readme-md-generator