{"data":{"allMarkdownRemark":{"edges":[{"node":{"id":"800a446b-0861-54ed-a2e3-a36e545abef1","frontmatter":{"category":"Coding","title":"The concept of SubForms - with React and Formik","date":"2019-07-02","summary":"Create forms at scale with Formik and Yup","thumbnail":{"relativePath":"pages/the-concept-of-subforms-with-formik/thumbnail.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAQCAYAAAAWGF8bAAAACXBIWXMAAAsSAAALEgHS3X78AAABcklEQVQ4y51UzcqCQBSdN+st3AluXOTel6htL2FBuDDaBFGRZGSEuOiHoKI2RbXsR/N83AFjkMbsuzCMjHfOnHvOnWHIRJIk71k2xLxssE+LsmSK1+uVC8pkYLTxdrvh8XjwOf3+dqgU8H6/o9PpYDAYwPd9TCYTuK6L6XSaCyoFfD6fsCwL3W4Xi8UC8/kc2+2Wg8dx/DsgMWw0GqjX6+j3+2i1WhiPx/8vmRjato3hcIjdbof9fs+Zinm5DLPOkQnNZpOzdBwHYRi+zcpzmmXZiQnX6xXL5RKbzYbrl2qXzRX3sE+aHA4HXC6XjxpFUYTj8SjVkokNS3E6naCqKi8zCAKsViveKqTlaDTi7VOpVNBut7nOUoYp4Hq9hmEYqNVqKJfLUBQF1WqVH6LrOkzThKZpKJVKOJ/P30umUkk3SiZDqFVIgtlsxtc9z0Ov1+P9mZYu6smK3mFZSDUUHUvbglxN2yQ76F8hl/OerSJP2R9ITMR6qwehxQAAAABJRU5ErkJggg==","width":395,"height":325,"src":"/static/631a33919834353b3dda8e8578592a5b/b3029/thumbnail.png","srcSet":"/static/631a33919834353b3dda8e8578592a5b/b3029/thumbnail.png 1x,\n/static/631a33919834353b3dda8e8578592a5b/8d141/thumbnail.png 1.5x,\n/static/631a33919834353b3dda8e8578592a5b/ee72c/thumbnail.png 2x"}}},"authorName":"Nicholas Peretti","authorDescription":"Software Engineer","authorAvatar":{"relativePath":"pages/the-concept-of-subforms-with-formik/avatar.jpg","childImageSharp":{"resolutions":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAUABQDASIAAhEBAxEB/8QAFwABAQEBAAAAAAAAAAAAAAAAAAMFBP/EABQBAQAAAAAAAAAAAAAAAAAAAAD/2gAMAwEAAhADEAAAAcKk+4zgAAf/xAAZEAEAAgMAAAAAAAAAAAAAAAACAQMQEiD/2gAIAQEAAQUCJlJVI4M6oXGs8f/EABQRAQAAAAAAAAAAAAAAAAAAACD/2gAIAQMBAT8BH//EABQRAQAAAAAAAAAAAAAAAAAAACD/2gAIAQIBAT8BH//EABsQAQACAgMAAAAAAAAAAAAAAAEAAhAgITFC/9oACAEBAAY/AgO2cmBlvTbX/8QAGxABAQACAwEAAAAAAAAAAAAAAREAIRAgQVH/2gAIAQEAAT8hBOpDNUohZx7hMll+40df/9oADAMBAAIAAwAAABBDwAD/xAAUEQEAAAAAAAAAAAAAAAAAAAAg/9oACAEDAQE/EB//xAAUEQEAAAAAAAAAAAAAAAAAAAAg/9oACAECAQE/EB//xAAcEAEBAAICAwAAAAAAAAAAAAABESFBADEQIFH/2gAIAQEAAT8QxBALK8VVkQLA7X54WBCyOzfKvBj0MduVz6//2Q==","width":50,"height":50,"src":"/static/9347eae31d09e05f032d02892f955d38/d2d31/avatar.jpg","srcSet":"/static/9347eae31d09e05f032d02892f955d38/d2d31/avatar.jpg 1x,\n/static/9347eae31d09e05f032d02892f955d38/0b804/avatar.jpg 1.5x,\n/static/9347eae31d09e05f032d02892f955d38/753c3/avatar.jpg 2x,\n/static/9347eae31d09e05f032d02892f955d38/31ca8/avatar.jpg 3x"}}},"headerImage":{"relativePath":"pages/the-concept-of-subforms-with-formik/headerImage.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAGCAIAAABM9SnKAAAACXBIWXMAAAsSAAALEgHS3X78AAAAUUlEQVQY06WOIQ4AMQgE+/8nYSoQaExFRQmSH4AovX7gkiM3djOZbecH7W2IiDGGqu69y7K7997NrFzOzLXWnFNEbrwm36vMjIgAQETl2194AJcvYFpZxM6mAAAAAElFTkSuQmCC","width":1280,"height":384,"src":"/static/8ce613d93c9ee2f1e3b248f2aabe8efc/26421/headerImage.png","srcSet":"/static/8ce613d93c9ee2f1e3b248f2aabe8efc/26421/headerImage.png 1x,\n/static/8ce613d93c9ee2f1e3b248f2aabe8efc/34a7a/headerImage.png 1.5x"}}}},"html":"

In the last few months I’ve been working a lot with forms. I had to do a large refactoring in one of AUTO1’s applications, and through all the research, I also encountered the term subform. The concept was troublesome not only for me.\nI found more than one issue on the Formik repository about developers asking for help.\nIn this article I'll try to clarify this concept and show you how to use it properly.

\n

What the heck is a subform anyway?

\n

If you’ve ever worked on a medium-large project with a reasonable amount of forms, you might have probably noticed that you could potentially reuse a lot of fields, sometimes even entire forms!\nThat’s the core of the subform concept: reusable components (fields or group of fields) that can be composed together to create bigger forms.

\n

At the beginning I had a lot of questions in my mind like:

\n\n

These questions and many others appeared while I was refactoring existing codebase. Many similar questions created by other developers appeared in the Formik repository as issues.

\n

Don’t get me wrong: implementing scalable validation for a single form is not that hard. The complicated thing is to keep validation and state flexible while you write your subforms. What does it mean? We’ll see that in a moment.

\n

How Formik can help

\n

Formik is an amazing library, one of the bests for this job, and here’s what it brings to the table:

\n

Auto-connected Field component

\n

Formik provides a Field component that, thanks to the React Context API, will be automatically connected to the Form component that wraps our Field, regardless of how deep our Field is in the tree.

\n

Yup validation schema

\n

Yup is a library to create validation schemas. This library is very similar to the prop-types of React, so it is very simple to start using it.\nFormik supports Yup natively, so you just need to define the schema and pass it to Formik, it will take care of the rest.

\n

So this is how Formik will make our life easier not only while creating subforms but also when we’ll need to maintain them!

\n

Enough talking, show me the code

\n

Let’s create our first subform! Before we start, we need to clarify what our subform will be responsible for:

\n\n

In our case, we're going to create a form that allows to create a new user.\nWe'll need to display the following fields:

\n\n

Just keep it simple. So, let’s create our NewUserSubForm directory and our fieldsNames file. It’s just a file that exports constants, don’t worry. It will look like this:

\n
//  UserSubform/fieldsNames.js\nexport const FIRST_NAME = 'firstName'\nexport const LAST_NAME = 'lastName'\nexport const EMAIL = 'email'\nexport const PASSWORD = 'password'
\n

Defining the validation schema

\n
//  UserSubform/validationSchema.js\nimport * as yup from 'yup'\nimport { FIRST_NAME, LAST_NAME, EMAIL, PASSWORD } from './fieldsNames'\n\nconst MIN_PASSWORD_LENGTH = 8\n\nconst REQUIRED_MESSAGE = 'This field is required'\nconst INVALID_EMAIL_FORMAT = 'Invalid email format'\nconst PASSWORD_TOO_SHOWRT = `The password must be at least ${MIN_PASSWORD_LENGTH} characters long`\n\nexport default yup.object({\n  [FIRST_NAME]: yup.string().required(REQUIRED_MESSAGE),\n  [LAST_NAME]: yup.string().required(REQUIRED_MESSAGE),\n  [EMAIL]: yup\n    .string()\n    .required(REQUIRED_MESSAGE)\n    .email(INVALID_EMAIL_FORMAT),\n  [PASSWORD]: yup\n    .string()\n    .required(REQUIRED_MESSAGE)\n    .min(MIN_PASSWORD_LENGTH, PASSWORD_TOO_SHOWRT),\n})
\n

We’ve just defined our validation schema regardless the markup of our form. This file just contains all the validation logic and has one responsibility. If in the future we’ll need to add some more validation options, we’ll just need to change it here.

\n

Now it’s time for the default values. Initial values are required from Formik because it uses controlled inputs. So, if you don’t specify those values, you’ll get and error from React as soon as you try to change the content of the input.

\n
//  UserSubform/defaultValues.js\nimport { FIRST_NAME, LAST_NAME, EMAIL, PASSWORD } from './fieldsNames'\n\nexport default {\n  [FIRST_NAME]: '',\n  [LAST_NAME]: '',\n  [EMAIL]: '',\n  [PASSWORD]: '',\n}
\n

Rendering the subform

\n

And now the master piece: The React component. Remember: we just need to use the Fields and not the Formik or the Form components.

\n
//  UserSubform/index.js\nimport React, { Fragment } from 'react'\nimport { Field, ErrorMessage } from 'formik'\nimport { FIRST_NAME, LAST_NAME, EMAIL, PASSWORD } from './fieldsNames'\n\nexport default class NewUserSubForm extends React.Component {\n  render() {\n    return (\n      <Fragment>\n        <Field component=\"input\" name={FIRST_NAME} />\n        <ErrorMessage name={FIRST_NAME} />\n        <Field component=\"input\" name={LAST_NAME} />\n        <ErrorMessage name={LAST_NAME} />\n        <Field component=\"input\" name={EMAIL} />\n        <ErrorMessage name={EMAIL} />\n        <Field component=\"input\" name={PASSWORD} />\n        <ErrorMessage name={PASSWORD} />\n      </Fragment>\n    )\n  }\n}
\n

And that’s it. In this phase we can test every single part of our subform: validation, the default values schema and the React component.

\n

A piece of advice: Formik sets the fields’ values in its state using the name property, but the cool thing is that it uses it like the Lodash set function. It means that we can write the name of a field like this: user.firstName. In this way Formik will create an object in its state called user, and then a property inside of user called firstName that will contain the value of our field.

\n

This mechanism gives us power to improve the flexibility of our subform. How?

\n

Making a subform flexible

\n

Let’s edit our component in a way that it will accept an optional property called namespace. If received, the component will prepend the namespace to every field name. In this way it will be easier to wrap all the subform’s values under a certain object in the main form.

\n
//  UserSubform/index.js\nimport React, { Fragment } from 'react'\nimport PropTypes from 'prop-types'\nimport { Field, ErrorMessage } from 'formik'\nimport { FIRST_NAME, LAST_NAME, EMAIL, PASSWORD } from './fieldsNames'\n\nexport default class NewUserSubForm extends React.Component {\n  static propTypes = {\n    namespace: PropTypes.string,\n  }\n\n  withNamespace(fieldName) {\n    const { namespace } = this.props\n\n    return namespace ? `${namespace}.${fieldName}` : fieldName\n  }\n\n  render() {\n    const { withNamespace } = this\n\n    return (\n      <Fragment>\n        <Field component=\"input\" name={withNamespace(FIRST_NAME)} />\n        <ErrorMessage name={withNamespace(FIRST_NAME)} />\n        <Field component=\"input\" name={withNamespace(LAST_NAME)} />\n        <ErrorMessage name={withNamespace(FIRST_NAME)} />\n        <Field component=\"input\" name={withNamespace(EMAIL)} />\n        <ErrorMessage name={withNamespace(FIRST_NAME)} />\n        <Field component=\"input\" name={withNamespace(PASSWORD)} />\n        <ErrorMessage name={withNamespace(FIRST_NAME)} />\n      </Fragment>\n    )\n  }\n}
\n

We don’t need to do that with the other parts of the subform, the main form will be responsible for that. And, about the main form, let’s see how to implement it!

\n

The main form

\n

Finally, we’re going to create our main form component. Let’s define its responsibilities just like we did with our subform. The main form will be responsible for:

\n\n

It's a lot of responsibilities, and that’s all right. The main form represents a specific point in the UI/UX where the user needs to insert some data. In our case, it could be a registration form, but it could also be a registration combined with a purchase, just like when you buy something from amazon and you agree to sign up in the process.

\n

The point is: A Form is a unique component that represent a specific use case, so it has to be designed accordingly. That’s why it makes no sense to create a “god-form” component with hundreds of props that decides which endpoint the form is going to use. It just creates useless complexity.

\n

In my opinion, the best way to organize this approach is to create a folder where you’ll store all your subforms. Every subform will be represented by its directory and it will contain all its parts: validation, values, fields and the React component.\nA main form, instead, should be created ad-hoc to fit the needs of a certain use case, for example inside a certain route.

\n

So, with that in mind, let’s proceed to the implementation. We’ll have our directory called registrationForm and it will have the same parts of a subform:

\n

Fields Names

\n
//  CreateNewUserRoute/form/fieldsNames.js\nexport { FIRST_NAME, LAST_NAME, EMAIL, PASSWORD } from './subforms/NewUserSubForm/fieldsNames'\nexport const USER = 'user'
\n

Validation

\n
//  CreateNewUserRoute/form/validationSchema.js\nimport * as yup from 'yup'\nimport { USER } from './fieldsNames'\nimport userValidationSchema from './subforms/NewUserSubForm/validationSchema'\n\nexport default yup.object({\n  [USER]: userValidationSchema,\n})
\n

Default values

\n
//  CreateNewUserRoute/form/defaultValues.js\nimport { USER } from './field Names'\nimport userDefaultValues from './subforms/NewUserSubForm/defaultValues'\n\nexport default {\n  [USER]: userDefaultValues,\n}
\n

The React component

\n
//  CreateNewUserRoute/form/index.js\nimport React from 'react'\nimport { Formik, Form } from 'formik'\nimport NewUserSubForm from './subforms/NewUserSubForm'\nimport validationSchema from './validationSchema'\nimport defaultValues from './defaultValues'\nimport { USER } from './fieldsNames'\nimport ErrorBanner from 'path/to/components/ErrorBanner'\n\nexport default class NewUserSubForm extends React.Component {\n  state = {\n    unknownErrors: null,\n  }\n\n  onSubmit = async (values, { setSubmitting, setErrors }) => {\n    try {\n      //  Send values somehow\n      await sendForm(values)\n    } catch (e) {\n      //  Map and show the errors in your form\n      const [formErrors, unknownErrors] = mapErrorsFromRequest(e)\n\n      setErrors(formErrors)\n      this.setState({\n        unknownErrors,\n      })\n    } finally {\n      setSubmitting(false)\n    }\n  }\n\n  render() {\n    const { unknownErrors } = this.state\n\n    return (\n      <Formik onSubmit={this.onSubmit} initialValues={defaultValues} validationSchema={validationSchema}>\n        {() => (\n          <Form>\n            {unknownErrors && <ErrorBanner errors={unknownErrors} />}\n            <NewUserSubForm namespace={USER} />\n          </Form>\n        )}\n      </Formik>\n    )\n  }\n}
\n

And that’s it! Of course, this is a very simple example, you could have different needs.

\n

Helpful advices on creating subforms

\n

I want to leave you with some advices that helped me while I was refactoring my codebase. It's good to have them in mind to ease the process of code refactoring.

\n

A subform should have only first level values in its state

\n

A subform should have only first level values in its state, which means that, when you design a subform, you shouldn’t get crazy about the shape of its values. It should be a flat object and every key should contain the field value.\nThis way it’s so much easier to write validations, default values and error handling (and why not, also the React component).

\n

You can avoid this advice only when you are using a subform into you subform. For example, let’s say you have an address subform. It has a lot of fields and a complex validation schema. In that scenario all the logic will be handled by the address subform and you’ll just need to orchestrate it in your own subform, just like you would do in the main form.

\n

Keep the validation schema extensible and scalable

\n

I didn’t do it in this article but the idea is to export a function instead of a schema. This function will accept parameters that will define the schema that you’ll get.\nIn this case you can toggle the “required” validation in some cases, or other kinds of validation.

\n

Example: let’s say that we want to make the “lastName” field optional, but not always. That’s how you could define your schema:

\n
//  UserSubform/validationSchema.js\nimport * as yup from 'yup'\nimport { FIRST_NAME, LAST_NAME, EMAIL, PASSWORD } from './fieldsNames'\n\nconst MIN_PASSWORD_LENGTH = 8\n\nconst REQUIRED_MESSAGE = 'This field is required'\nconst INVALID_EMAIL_FORMAT = 'Invalid email format'\nconst PASSWORD_TOO_SHOWRT = `The password must be long at least ${MIN_PASSWORD_LENGTH} characters`\n\nexport default function validationSchema(mandatoryFields = { [LAST_NAME]: true }) {\n  return yup.object({\n    [FIRST_NAME]: yup.string().required(REQUIRED_MESSAGE),\n    [LAST_NAME]: yup.lazy(() => (mandatoryFields.lastName ? yup.string().required(REQUIRED_MESSAGE) : yup.string())),\n    [EMAIL]: yup\n      .string()\n      .required(REQUIRED_MESSAGE)\n      .email(INVALID_EMAIL_FORMAT),\n    [PASSWORD]: yup\n      .string()\n      .required(REQUIRED_MESSAGE)\n      .min(MIN_PASSWORD_LENGTH, PASSWORD_TOO_SHOWRT),\n  })\n}
\n

Now you have a scalable validation schema.\nIn this way you can always decide if a certain field is required or not. Also, you can extend that function to add parameters. In this way, if your subform scales, you’ll just need to add parameters and adjust the code in the subform accordingly, but every single form that uses your subform won’t be affected by these changes because everything is retro compatible.

\n

Conclusions

\n

Dealing with forms is not easy. Of course, there are simple cases, but there are also trickier ones. This was my way to organize the code, and of course, it’s not perfect.\nI’m sure there are other thousands amazing ways to solve this problem better than this, but for now, this is the best way I’ve found to keep everything testable, maintainable and scalable.

\n

I hope this will help you, and if you have a better approach, I’m looking forward to reading it!\nUntil next time, happy hacking!

","fields":{"slug":"/the-concept-of-subforms-with-formik/","tags":["formik","forms","react","subforms"]}}},{"node":{"id":"4847d312-706f-5678-9e9e-1a333f42095e","frontmatter":{"category":"Coding","title":"How we use ES6 generators to simplify our React Redux application code","date":"2019-04-04","summary":"How we use ES6 generators instead of thunk to simplify our React Redux application code and improve productivity","thumbnail":{"relativePath":"pages/es6-generators-react-redux/thumbnail.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAACXBIWXMAAAnLAAAJywEjDYgKAAADmUlEQVQ4y3VV2W/MURQemUY7+7Szd2Y681umLSHWB4TW1nqo5YUisYVIVGsJEXtrryUIam9Va0nQ1hoULYrEFhL8ASS2+A94+Zxzfp0xpR5ucnPPud893znfOdekqioUWqqiyFI0DVooAN2bDTUagaLrYpdFez5jm5YbFF+5k8SgZUoHVFQCi4QRmlIOb8V65A0fAd2Xk7rA++iIMfAsq0Zu2XRo4dweoClAOaDXtYAPgTlLkNn6Cq5tx5HV+hLu6sMUVRRqLM84a3kB95Y6ZLa9RnDGAmhBP4HqBsP0CIUq0bCdvInQtNnIt5gRGzgIjgMXYD/SAvvRNjj3NSPefwAKMvsgMHuxnHMQDJiKUPmLsvVMOyKjxxtUiL4WCsL89BsyHn+WaNS8qPiHJ5bJ42o89ifHEmEyqXpCAOxHWxEZW4qEwyIAjsOXkb1uL7I37Ifj4EWJKGHPQrhkChyHLlEeQ1AS+amgTCm65Kj7veJkO3UL2RsPwNr0AKYPv2Bt7oDlXKexb7wn4Lb623DsPw/d4+7Oo9YdYTwu1fItXi0AfW++Q+a1t/Cs2i5Uo6PHIV7QD0pBISLFpTA/+w7Pyq3ix8t69j7886sk/xIh64oTb23qoAsliA0eRrm5IZF6K9ZRdWNw7m2Cc/cZ0SBLhqnbTtxAbNBQhCeUwXKxS+wsOZNv0SoyXpfQOeGsNeeeRmQ8/ER7j9Ay/YAsZ22DpMX85AtcO06SwHMMoZMfp8A/r5IAF66U1wSQohFAei2j86OxJ6kkAV27TgtgRtdn2teLXYLwM+Ad+OcuTaNMuYiOKibtDRY5sMa8S9bKBb7MEWmRXIMy+QvlIcNJEZNgucCUG6QWqaLwZcv5R1SQN9IF3sqNMHd9kUdEFrQiYyZQob7CW7VJ/Pre+iCF9C9Y/qcohiAN2bCI7ceukrjvwl1TJw+Y3v+EpblTpJPcuzcfEmkxC06BFvSlySZN2Fwle12rVDvhssnUsR+5IsLOWVNLthY5SzitiBRNlHY0JlLiL2EnW49esTa2i/ak9ciZRcsVZ6rcFQJANga0NtxNa9tk6/UYDiGiQsNh6izkZ5kRL+wH187TUiSWFlc/Xtgf+TQceNJwetK7pNfx5Z9TIeOLx1bWledw1dYbo4kk5dp5Ss7YxoULzFxk5E/vZXz1GLAUIcsjOrLI0Fo3JRmwVHXPihqEJpf/f8D+9wsg8H++ADqTgRDq/Qv4DWMLuHUxNoXrAAAAAElFTkSuQmCC","width":325,"height":325,"src":"/static/2bee11a830bacc5ae9006df56b20c33a/b3029/thumbnail.png","srcSet":"/static/2bee11a830bacc5ae9006df56b20c33a/b3029/thumbnail.png 1x,\n/static/2bee11a830bacc5ae9006df56b20c33a/8d141/thumbnail.png 1.5x,\n/static/2bee11a830bacc5ae9006df56b20c33a/ee72c/thumbnail.png 2x,\n/static/2bee11a830bacc5ae9006df56b20c33a/5dfa8/thumbnail.png 3x"}}},"authorName":"Chirag Swadia","authorDescription":"Chirag is a Software Engineer at AUTO1 Group.","authorAvatar":{"relativePath":"pages/es6-generators-react-redux/avatar.jpg","childImageSharp":{"resolutions":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAUABQDASIAAhEBAxEB/8QAGAABAAMBAAAAAAAAAAAAAAAAAAECAwT/xAAXAQEBAQEAAAAAAAAAAAAAAAAEAwAB/9oADAMBAAIQAxAAAAGIveV5aObk0FjsCs//xAAbEAADAAIDAAAAAAAAAAAAAAAAAQIRIRIiQf/aAAgBAQABBQKnxmHTMGhGz0l9f//EABoRAAICAwAAAAAAAAAAAAAAAAABAhAxMkH/2gAIAQMBAT8B7U9mLB//xAAZEQABBQAAAAAAAAAAAAAAAAAAAQIQMTL/2gAIAQIBAT8BhuRbP//EABsQAAIBBQAAAAAAAAAAAAAAAAARAgEQIDFB/9oACAEBAAY/AmKcEatzCh//xAAbEAEAAwADAQAAAAAAAAAAAAABABEhMVFh8P/aAAgBAQABPyEnrfkRsPknmGxTsy8Dqp82W0JRuRFFn//aAAwDAQACAAMAAAAQ+Dj/AP/EABgRAAMBAQAAAAAAAAAAAAAAAAABETEQ/9oACAEDAQE/EG5ovBkf/8QAGBEAAgMAAAAAAAAAAAAAAAAAADEQESH/2gAIAQIBAT8Q2lCBh//EABwQAQADAQEAAwAAAAAAAAAAAAEAESExUXGB8P/aAAgBAQABPxCyt4AerkU0XY8TkPRXxBSQfql1NpWO/co8qKgOPZRgcYmBU9n/2Q==","width":50,"height":50,"src":"/static/8cf5c37636309895b29dd7ce5f1fcf28/d2d31/avatar.jpg","srcSet":"/static/8cf5c37636309895b29dd7ce5f1fcf28/d2d31/avatar.jpg 1x,\n/static/8cf5c37636309895b29dd7ce5f1fcf28/0b804/avatar.jpg 1.5x,\n/static/8cf5c37636309895b29dd7ce5f1fcf28/753c3/avatar.jpg 2x,\n/static/8cf5c37636309895b29dd7ce5f1fcf28/31ca8/avatar.jpg 3x"}}},"headerImage":{"relativePath":"pages/es6-generators-react-redux/headerImage.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAGCAYAAADDl76dAAAACXBIWXMAAAsSAAALEgHS3X78AAABWUlEQVQY022QS0/CQBSFOzMtFLCdtsOrPOQRIPJogIILgkY0GqKJG5cu3GqMxIULExOJG/9s/0N7nBbjRiaZnJs7ky/nHEWRx63WRDqVCjRdR344DUV/jPxohlQmC0YpNE2Dqqp/SqkC+8BFuzBHTucRYzSK3xzHOY95SrXXF1KCbK2Fzv1T6L1+ofewQa7egtz/u0Sh6BZO0HBmOLT9SO4iohAYhrED6ooidJMHldUNvJdt6G22Uj/hXtyiO/TgTyeY+j4WiwUKpTxEtomheyVhE4wq64jr5RgKi/86LJZdQQkJ7MEUg8f3cPz2jeHzB+zRHLIKcM5hmqZUE2ktg4bto1NYomZ56BVPo6Yzjwgh8Z8d0G22BZGRWTaH8vIyrK/vUDm7hpoz9kauWqMk8lFphZY4jspGL3HIubUD5oUQjKlB0o+qhokythf21yOhiVLCkg7jOXb4A0fehWKiiDXIAAAAAElFTkSuQmCC","width":757,"height":236,"src":"/static/c49511e796013b6394df522c11a4a9fc/7eaf7/headerImage.png","srcSet":"/static/c49511e796013b6394df522c11a4a9fc/7eaf7/headerImage.png 1x"}}}},"html":"

Background

\n

When I first started working on React/Redux, the very first choice of library I used for handling asynchronous actions was Redux Thunk as its maintained by the authors of Redux, and is very popular as well. Consider the following example, where an action type is being created for incrementing a counter and a corresponding action creator for it.

\n
const INCREMENT_COUNTER = 'INCREMENT_COUNTER';\n\nconst increment = () => ({\n  type: INCREMENT_COUNTER\n})
\n

Using redux thunk, an async action creator can be created as follows

\n
const incrementAsync = () => {\n  return dispatch => {\n    setTimeout(() => {\n      dispatch(increment());\n    }, 1000);\n  };\n}
\n

Pretty simple till now.

\n

The Problem

\n

Redux Thunk is easy to understand, but the problem arises when the application scales, and as the need for dispatching condition-based actions grows with the application, it leads to unmaintainable code. For example, consider the below code

\n
const makeSandwichesForEverybody = () => (dispatch, getState) => {\n  if (!getState().sandwiches.isShopOpen) {\n    return Promise.resolve();\n  }\n\n  return dispatch(\n    makeASandwichWithSecretSauce('My Grandma')\n  ).then(() =>\n    Promise.all([\n      dispatch(makeASandwichWithSecretSauce('Me')),\n      dispatch(makeASandwichWithSecretSauce('My wife'))\n    ])\n  ).then(() =>\n    dispatch(makeASandwichWithSecretSauce('Our kids'))\n  ).then(() =>\n    dispatch(getState().myMoney > 42 ?\n      withdrawMoney(42) :\n      apologize('Me', 'The Sandwich Shop')\n    )\n  );\n};
\n

In the above code, there are too many callbacks and the code does not look clean. Also, it would become complex if more conditions are added to it later on. Then, how to simplify this?

\n

ES6 Generators to the rescue

\n

For our customer-facing websites like wirkaufendeinauto and AutoHero, we are neither using Redux Thunk nor Redux Saga. Rather, we are using a very simple and lightweight npm module Redux Actions Generators developed by our very own Alexander Afonin, who works as a Senior Software Engineer at Auto1.\nIf this module is configured as a middleware in the React application, the above code can be simplified as shown below

\n
const makeSandwichesForEverybody = () => function* ({ getState }) {\n  if (!getState().sandwiches.isShopOpen) {\n    return;\n  }\n\n  yield makeASandwichWithSecretSauce('My Grandma');\n  yield [makeASandwichWithSecretSauce('Me'), makeASandwichWithSecretSauce('My wife')];\n  yield makeASandwichWithSecretSauce('Our kids');\n\n  if (getState().myMoney > 42) {\n    yield withdrawMoney(42):\n  } else {\n    yield apologize('Me', 'The Sandwich Shop');\n  }\n};
\n

Now you are ready to tackle the growing complexity with ease. Also, the code is clean and readable.

\n

One question that might arise is that why not use async/await with thunk actions which could have solved the problem that is being discussed earlier. But, there are advantages of using generators instead of async/await thunks which are listed below -

\n

Testability

\n

Redux Thunk returns promises, which are more difficult to test. Testing thunks often require complex mocking of the fetch API, Axios requests, or other functions. With generators, you do not need to mock functions wrapped with effects. This makes tests clean, readable and easier to write.

\n

Error Handling

\n

The best part about the Redux Actions Generator module is that you can catch all errors at one place, without the need to write multiple try catch blocks in different actions ( you can if you want to, but not mandatory ) With redux-thunk, this is not possible and you have to write error handlers everywhere, which makes the code look less readable.\nTo use this common error catching functionality, you can configure it while creating the store as shown below -

\n
const catchError = error => console.error(error); \nconst middlewares = applyMiddleware(createGeneratorMiddleware(null, catchError));
\n

Once you do this, your actions can become clean and more readable. For example, the below code...

\n
const someAction = () => function* ({ api }) {\n  try {\n    yield api.loadSomeItems();\n  } catch (error) {\n    // handle error logic\n    console.log(error);\n  }\n}
\n

can be replaced with...

\n
const someAction = () => function* ({ api }) {\n  yield api.loadSomeItems();\n}
\n

In this way, all the uncaught errors will be caught with the catchError function.

\n

Enough of Making Sandwiches

\n

Let's get to some real life example on how we use this pattern in our code. Consider the Auto Kaufen page on our wirkaufendeinauto website where we show a list of ads, filters, header, footer and some other content.

\n

For this module, we have some actions like

\n
const loadAds = (filters) =>\n  function*() {\n    // filter is an object with some information like {make: 'Audi', model: 'A3'}\n    \n    const { ads: result } = yield api.findAds(filters);\n\n    // Once we get the ads list, we just save it in the redux store\n  }\n\nconst loadSimilarAds = (filters) =>\n  function*(){\n      //  this is same as loadAds, but the API endpoint from which it fetches data is different\n  }
\n

Similarly, we have other actions like loadDataFromCms, trackGtmEvents etc. Now the action which will be called when the main component mounts, will be as shown below

\n
export const loadPage = () => \n  function*({ getState }){\n      yield loadDataFromCms('header');\n\n      const filters = yield getFiltersFromStore(getState());\n      yield [\n        loadAds(filters),\n        loadMakeModelSubtype(filters),\n        loadDataFromCms('home')\n      ];\n\n      // If no ads found, we try to find similar ads which might interest the user\n      if( getState().ads.length === 0 ) {\n          yield loadSimilarAds(filters);\n      }\n  }
\n

As you can see, in the above code we are making multiple API calls, some are in parallel, and some are fired conditionally based on the results of the previous API calls. This way our redux actions look clean and are easy to debug and maintain.

\n

Summary

\n

So this is how you can make use of the ES6 generators to simplify your React application code. Comments and suggestions are welcome.

","fields":{"slug":"/es6-generators-react-redux/","tags":["auto1","engineering","react","redux"]}}},{"node":{"id":"7cae20df-634c-53fc-9b57-d14a4a98b03e","frontmatter":{"category":"Social","title":"Embeddable Lightweight React Widgets","date":"2018-12-11","summary":"This article will introduce two approaches to integrate lightweight react apps (we will call them widgets) that can be embedded in any project","thumbnail":{"relativePath":"pages/embeddable-leightweight-react-widgets/thumbnail.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAQCAYAAAAWGF8bAAAACXBIWXMAABYlAAAWJQFJUiTwAAACDElEQVQ4y6WSa0tUURSG92+q6GL3soIypA+FRQbWkLcZtbxEQmpoF7MUoYxKbIgmJYmSoiDDz/2EOmdGZ+aM5khfDwNJ+2nts3Ps4uSBPjyss9c+e6137XerVCpFMpnExP9hpYYKfcgcCIEylUPhuqFQ6XSa9ZgzZL1QKM/zKEk2S8bL8TWX4Xu8l+XhFpbvtq1BaxHlisxSmBE+J1Pkk5+gsxIim6BhO9RuhfObLbVboH4b1FnUeka4s3MszTpw9RS6aQ/6Qjn60lF01wnL5Up0y37JHwhQKdehJI6DK0WXjMKeKnRsN0R3wmAjTA5b7rVZ1dKI5n3icu4LReYNixZZp3ILOAt58tm0LVhfBt1V8OQaTCfgwzgk+qH3NJhmolQVJoYojA9i4x0KT29RSAys5hK3+TYzKYeq0UaJjIgYxNs4vIvbgp3HoGmvLRhcqOlcJxfdLMmhKPRV24s2Bc5tgJF29PUaaJRxo7usorFuoQf6I5LfsTqyvngQ3XoILQvddwY98xz9bADdcYRgLyZGjF5B36hBS7HAFLPXUYFuPywGVfw0pTxABSoMRmVMut88C13HrULTObIR7neIyyftt8mtPJMgymQNZUWU/+Yx/mshiGP4rx7iTz2ya8PUKP7H9/jTE/gvRuz+n7x8YJFv5YqbvyEOB/yay3i43vzf+TX49zss4hLuP4cfa1IV+zKNxLYAAAAASUVORK5CYII=","width":402,"height":325,"src":"/static/dd3ba552f348daf0d9beb74158081069/b3029/thumbnail.png","srcSet":"/static/dd3ba552f348daf0d9beb74158081069/b3029/thumbnail.png 1x,\n/static/dd3ba552f348daf0d9beb74158081069/8d141/thumbnail.png 1.5x,\n/static/dd3ba552f348daf0d9beb74158081069/ee72c/thumbnail.png 2x,\n/static/dd3ba552f348daf0d9beb74158081069/5dfa8/thumbnail.png 3x"}}},"authorName":"Kareem Elbahrawy","authorDescription":"Kareem is Senior Frontend Engineer at AUTO1 Group","authorAvatar":{"relativePath":"pages/embeddable-leightweight-react-widgets/avatar.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAACXBIWXMAAAsSAAALEgHS3X78AAAFRUlEQVQ4yyWUa1BUZRjHz8e+9MEP1SiWgrvsLrDAooBAYHIzHanwMpmZt3FMI8NMRSdzwEuYiAgusAu4BMsuuyzLXpDLAuH97piXvKIoCKiJWVYz9enXA334z3vOM+f83v/z/M97lJHBuwwN3Gbo0W2GB+7Q33d9/Pr50L1x/TooetzH6FAfL4b7+O3JA1G/6CEvRvoZHX7A6IjURu7zx9OHKAMPbvBs7MXHd3km6rt5iVtXz/P7037+fD7Av6+e8UQ2ePLwJk9l45dSH7p/nd8F+vfoY17JMy8F/lyMjW2o/HL1LCOPbomTu/LiLW5fPcfxrlbuXrvA0L3r+Jrq8DqPcPlUgJuXTnDj4ikunezmyukefhPXf78YFPAgf4n+eTmMcuPKaU71tjPcf2t89zvXL+Ky19PpaWbDmhW88fpraN6ZSKI+lB05qzgd8HHj0hm6fU0M3PmZZ2JiVDp8+ugmg/euoXS0NeNvsXOs08fJnlbavE5qzCZKiw+QFhvNR4mxLEpO4IM4A+kGHaX5ebjtNmpNldgsZurNRkyHSqg2llB16AcUU9l+qkr2UrF/F8Z9+VQW78ViLCYvdz3ZSXHs/HQh3y75kMK1y1gyK4Fl6Ql46spw1JRQX7EPl+UglQd3U7AjD2PRPpTCb3M5lP81Zbs2iTZTWrCJw3s3UZC7nIXJ8axMS+KbxfNZm5XGuqwMNn6cSYNxK+WFX2Dcu57yPespK5C1cBvmsp0oFpNR7B6ktlJU8b8ctZWYC3eS80EGOfNS2Zg9h1XpSXy3fDGm3BVYindTuGMzu/I2cKBgK3vyvmJzzjq25K5E8bmdHPU4ZXYOumSevZ0eLp/9iYC7QdpdwPcrl1C4aikHPl9G9ebVdFYXc+HsCY73tNMb8NPb7uZYhxdLZRkF2/NQGhstOB0WXM5aPG4rbT473R3NnJGA8pcvYuuCuez4JJtt2al4Du/m3IkAPRJgV0cL7f4mGo4Y6TraRG+Xl8BR1xiwFocAm1x1tHgaaPXZxKmL86e6KN6SI6A55I8FsyiDs946qffQJoB2kd/nwO+10d7qEEmXfieKzVYz7tApDt3uegLtzZwTWK2plKVpyXy3eK7McTar56ZRXr4fe3cLAXHj8drx+hplteGTrnxy7fM7UKwN5nGYSxwelWJFaRGLsubyfmoK2ZLylx9msnBOJu+npRMVE01mzmcYPRY5KYHx51sF1ioO/f5GWloaUH60lGOtM2G3mvFLEPPSZvPWhAmERYSTEh9HltzPiIlBowklIiyMMJ2W9xJm0GY1crLbTXvL/2PyiTweK0ptdRn1MthGq0AtFcTNiCE4VI1WFGaIRquPIDRchyZMh0EfSaRKjXryZPSTgsjYsobS0166PAJsscqJE6BVHNrrKmhqqKL6cBGRiTMJmTpVzu8UVHodoVGRaCIi0Ov1xEdGEz5NRXhIMOqgybxp0JNeV4S30yU/kR/xyOiUsdjra0ppqjdRU1mMPikBVdDb6KYINCpCFIVWgLHRMSREGdCrBBg8Fa1azdSQaQTNTyfPZaZDMnDZq6RlgVhrynAK0FpbQcKsJFQTJxGj1ZIYF0+YAPWi5Nh4kgzTiRJQuHQQqpqGSqfjLa2GlO3rcTlq8DRWozis1TilZbfNhE3CSU1NRT0xiDhpMTMpmZTYmURrw5muCyMx2oBBoxGHIWhkxqFSmxyiwvBxFs2eOvyNNShF+37AXGnGYaunylxOSmIyEcFqkmNiyUh6l9nxM8eD0MpMx0D6aSFEhISMh6bW6pgiQJV8p4eOlNAmM/wPrWQIzBh2TMkAAAAASUVORK5CYII=","width":50,"height":50,"src":"/static/ea2656d13f68652e7e988d1a80c98c8b/45876/avatar.png","srcSet":"/static/ea2656d13f68652e7e988d1a80c98c8b/45876/avatar.png 1x,\n/static/ea2656d13f68652e7e988d1a80c98c8b/eb85b/avatar.png 1.5x,\n/static/ea2656d13f68652e7e988d1a80c98c8b/4f71c/avatar.png 2x,\n/static/ea2656d13f68652e7e988d1a80c98c8b/9ec3e/avatar.png 3x"}}},"headerImage":{"relativePath":"pages/embeddable-leightweight-react-widgets/header.png","childImageSharp":{"resolutions":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAGCAYAAADDl76dAAAACXBIWXMAAAsSAAALEgHS3X78AAAA50lEQVQY032OsUvDQBTG+0e6OhYXFzcXXXQRxUEQpODgJIg4OImubiKiUoRCPC6X0FqSixbbhOQuP5ujOtRrP/h4D973/XgtZqrr2rlRWZbkee5cFIV3Npn5XqOWD6i1RgiBUoo4jpFSosKQKIoY9Pu8BwFJkiwHzh8n4zF6WsrS1DnJMvTXaDo/+Z7kXpj3w9/AIM14E5KeVM6i+4J4fSJ4fmQYhd7Ogg+t20fdBz7uLhne36BvL2BrBU63YXcVznZwCGsXf/gHtMbt9rqD2WtjTjYx+2tUh+tU5wdURxuYq+NZ/j/wB5xHx6fGez75AAAAAElFTkSuQmCC","width":1280,"height":420,"src":"/static/4786c8105880f38270b7cd8b2ee3faaf/26421/header.png","srcSet":"/static/4786c8105880f38270b7cd8b2ee3faaf/26421/header.png 1x,\n/static/4786c8105880f38270b7cd8b2ee3faaf/34a7a/header.png 1.5x,\n/static/4786c8105880f38270b7cd8b2ee3faaf/77cb2/header.png 2x"}}}},"html":"

\"We need to re-write EVERYTHING!\"... It's understandable that a huge technical debt is created during the first period of building a company app, a lot of business needs, a lot of deadlines and smaller teams. And for webapps where a proper frontend solution was not considered, most of this technical debt falls on frontend and by time it becomes harder and harder to refactor till it reaches a point where the right way to refactor it is to re-write it. But that's not an option sometimes, isn't it?

\n

As an alternative, This article will introduce two approaches to integrate lightweight react apps (we will call them widgets) that can be embedded in any project.

\n\n

React Widgets: Traditional Approach

\n

React widgets implemented directly in your codebase.

\n

Create a similar folder structure to this:

\n
.\n├── server\n    └── ....\n├── frontend\n    ├── widgets\n        ├── login.js\n        └── subscribe.js\n    └── components\n        ├── Login.js\n        ├── Subscribe.js\n        └── ....\n├── dist #ignored\n    ├── widget_login_bundle.js\n    └── widget_subscribe_bundle.js\n├── webpack.config.js\n└── package.json
\n

/frontend/widgets directory will contain entry points for all the widgets, each file inside should render a react app in a corresponding DOM element id

\n

For example /frontend/widgets/login.js

\n
import React from 'react';\nimport ReactDOM from 'react-dom';\nimport Login from '../components/Login';\n\nReactDOM.render(\n    <Login />,\n    document.getElementById('widget:login'), // <-- NOTE the element id\n);
\n

webpack.config.js will look like this

\n
module.exports = {\n    entry: [\n      './frontend/widgets/login.js',\n      './frontend/widgets/subscribe.js',\n    ],\n    output: {\n        filename: 'widget_[name]_bundle.js',\n    }\n    ...\n}
\n

Now running webpack from the project folder will create two bundle files widget_login_bundle.js and widget_subscribe_bundle.js in the dist folder.

\n

Now you can use a widget in one of your views like this

\n
...\n<div id=\"widget:login\"></div>\n<script defer src=\"/dist/widget_login_bundle.js\" />\n...
\n

Pros

\n\n

Cons

\n\n
\n

React Widgets: Standalone Approach

\n

In this approach we will keep all frontend in a separate repository and have an npm script to generate an html and bundle js file for each widget and upload them to a CMS.

\n

But first, A new database model need to be introduced that will hold the widget data (name and html) and there should be a way to upload assets to a content server.

\n

For example you may expose two web service APIs similar to this:

\n\n

The folder structure will be similar to the previous approach but this time in a separate repository:

\n
.\n├── frontend # Same as before\n├── dist # Same as before\n└── scripts\n    ├── deployWidget.js\n    └── ....\n├── webpack.config.js\n└── package.json
\n

/scripts/deployWidget.js is a nodejs script that expects a --widget argument and will do the following:

\n\n
const path = require('path');\nconst argv = require('yargs').argv;\nconst uploadAssetToContentServer = require('./uploadAssetToContentServer');\nconst createOrUpdateWidgetEntry = require('./createOrUpdateWidgetEntry');\n\nconst deployWidget = async ({ widget }) => {\n    const bundleFile = path.join(\n        process.cwd(),\n        'dist',\n        `widget_${widget}_bundle.js`\n    );\n    const uploadedUrl = await uploadAssetToContentServer(bundleFile);\n    const html = `\n        <div id=\"widget:${widget}\"></div>\n        <script defer src=\"${uploadedUrl}\"></script>\n    `;\n    await createOrUpdateWidgetEntry({\n        name: widget,\n        html,\n    });\n    console.log(`widget ${widget} deployed successfully`);\n};\n\ndeployWidget({\n    widget: argv.widget,\n}).catch(console.error);
\n

NOTE: I encapsulated the logic to upload the bundle file and save widget entry in uploadAssetToContentServer.js and createOrUpdateWidgetEntry.js respectively, which you will need to implement.

\n

In package.json

\n
...\n\"scripts\": {\n    ....\n    \"deploy-widget\": \"webpack && ./scripts/deployWidget\"\n}
\n

And now to deploy the login widget:

\n
npm run deploy-widget -- --widget login
\n

Going back to the backend repository, You can render a specific widget using the html value saved in DB, for example

\n
...\n{{ getWidgetHtmlFromDB('login') | raw }}\n...
\n

Pros

\n\n

Cons

\n\n
\n

What's next

\n","fields":{"slug":"/embeddable-leightweight-react-widgets/","tags":["auto1","engineering","react","widgets","refactoring","modularity"]}}}]}},"pageContext":{"slug":"/tags/react","tag":"react","categories":["Architecture","Coding","DevOps","Engineering","ProjectManagement","QA","Social","TechRadar"]}}