react-i18next VS react-hook-form

> It’s important to be aware of what you are getting if you go with React, and what you are getting is a far cry from what a framework would offer, with all the corresponding pros and cons.

Would you like to elaborate on that?

In my experience, with something as great, size/ecosystem-wise as React, there will almost always be at least one "mainstream" package for whatever you might want to do with it, that integrates pretty well. Where a lot of things might come out of the box with a framework, with a library I often find myself just needing to install the "right" package, and from there it's pretty much the same.

For example, using https://angular.io/guide/i18n-overview or installing and using https://react.i18next.com/

Or something like https://angular.io/guide/form-validation out of the box, vs installing and using https://formik.org/

Or perhaps https://angular.io/guide/router vs https://reactrouter.com/en/main

Even adding something that's not there out of the box is pretty much the same, like https://primeng.org/ or https://primereact.org/

React will typically have more fragmentation and therefore also choice, but I don't see those two experiences as that different. Updates and version management/supply chain will inevitably be more of a mess with the library, admittedly.

Now, projects like Next https://nextjs.org/ exist and add what some might regard as the missing pieces and work well if you want something opinionated and with lots of features out of the box, but a lot of those features (like SSR) are actually pretty advanced and not always even necessary.

In a recent project I've been using react-i18next so I'll use its syntax for the examples, but pretty much every library works similarly.

react-i18next

i18next - You can find documentation and resources for using i18next at react.i18next.com. i18next is a popular internationalization framework for JavaScript, including React. It provides a comprehensive solution for handling translations, formatting, and more.

So far, we’ve been using a utility createLocalizedString to create and use the LocalizedString type. This utility is only really practical in unit tests. For real applications, we’ll want to use a translation function from react-i18next or next-i18next to do the heavy lifting. Then we just wrap the translation functions that are provided in order to use our type:

Website: https://react.i18next.com/

If you are talking about handling translations for your application, take a look at https://react.i18next.com/

I will be supporting Korean as a part of the beta. I have to look deeper into https://react.i18next.com/ in order to understand what it provides. My goal is for engineers to be able to click a single button and have localizations always up to date in their codebase, not delaying shipping a new version or having to even think about it.

With the new react-i18next version, when loading multiple namespaces, t function will infer and accept the keys for the first namespace. So this pattern is now accepted:

react-i18next

React Hook Form is one of the most popular libraries for building forms in React apps with over 39k stars on GitHub. The library has no external dependencies according to Bundle Phobia.

Link: https://react-hook-form.com/

The idea here is to first define an array of field names for each provider. We'll also need a map with more detailed information about each field. This map will contain the field name, label, type, and validation options. We'll use this map to render the form fields and also to validate the form. Finally, we'll have a Form component that will render the form fields based on their type and handle the form submission. We'll use React Hook Form to handle the form state and validation.

Now we need to install React Hook Form because that is the package we are going to use for building our form. We also need to install the package for SendGrid. cd into the sendgrid-contact-form folder and then run this command to install the packages:

Imagine someone unknowingly unleashing heavy computation on a component without useMemo. That computation will run on every component re-render. Not only that, The dependency array in your hooks (useEffect, useMemo, useCallback) are also checked in each re-render. It's like a double whammy for performance pitfalls! I know that you can avoid this by some technique like what react-hook-form done, but remember thats an extra complexity.

But now, all those difficulties are gone since I found React Hook Form and zod.

This will greatly simplify the handling of AJAX forms in React - like for instance for a search form. But again, this may not be enough to get rid of third-party libraries like React Hook Form, which does much more than just handle form submission (validation, side effects, etc).

We could consider to do all these steps specifically for each data-set; of course this isn't an efficient approach due to the amount of repeated code involved. So what if we could abstract all this in a single management? A way to do this could be using a simple configuration in which we specify each aspect for each input (its type, validations required and so on). And we can do this thanks to the extreme flexibility provided by React Hook Form.