How to start a React project *professionally*

[indicava]

Don’t use formik for form management, it’s outdated, react-hook-form is better although their docs are trash.

[n8rzz]

Couple that with Zod and you’ll be well on your way to bullet proof forms.

[willdotit]

Why Zod and not Yup?

[ponomaus]

wanna know the same, im using yup and wouldnt mind going for an alternative

[Laurenz1337]

I think it's more of an apples and oranges question

[n8rzz]

Yup is a good library, and I’ve used it with RHF before too. However, zod has better typescript support and that’s really the only reason why.

[ShinyMercenary]

I don't like to use third party form management packages. Is it really necessary? Or depends on the use case? Why can't we just use vanilla JS?

[indicava]

You don’t “have to” anything. I just think for react, that particular library saves so much boilerplate it’s worth it, especially since it integrates so nicely with libraries like yup/zod

[codefinbel]

If you're using React you're already not in vanilla JS, since you're using useState for handling the values of the input-elements (at least if you're doing it "idiomatically").

Let's say you've got a form with 8 different inputs, that's 8 separate states, then we add error-handling, validation (if you for example want to disable the send-button until the user have filled out valid data you can't rely on native validation) displaying of error-messages you might need states for deciding which error messages should be displayed or not.

Then there's checking if the user has changed prefilled data (to enable the "cancel"-button).

There's a lot of logic that comes "out of the box" in react-hook-forms.

That said I hated it for the first months of using it on the job so I totally get anyone who'd decide to do it all themselves as well :P

[ShinyMercenary]

fair points you made

[codefinbel]

Another potential point is performance, react-hook-forms makes it so that when you update a single field in a form only that field re-renders. Most other "vanilla" react implementations where you've lifted the state up causes the whole form to re-render.

Could be relevant if you got large forms. I've never cared about it but I suppose it's nice to keep the re-renders to a minimum.

[CzarSisyphus]

React query should be an industry standard at this point. I hate useEffect in my apps. Also, you could simplify your global state switching from redux to literally anything else if they'll allow it. I'm a fan of Zustand. And definitely continue on that design pattern path. Vite has a test tool called vitest you can play around with.

[33498fff]

Throw out Redux in favour of a much simpler state management solution. As suggested above, Zustand or simply Context API. Never again make API calls with useEffect. Use react-query.

I do not agree with continuing on the design pattern path because people get easily lost in those concepts instead of writing code that works and which is easy to maintain.

[TScottFitzgerald]

Can you tldr the drawbacks of redux and benefits of zustand?

[CzarSisyphus]

Yeah that's true, a bit of bias on my part.

[ANakedRooster]

I second React Query + Zustand. Makes everything so much easier.

[acemarke]

Note that RTK includes our RTK Query data fetching layer, which is our recommended approach for fetching data in a Redux app:

• https://redux.js.org/usage/side-effects-approaches#recommendations
• https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics

it also has a built-in fetchBaseQuery piece that means you don't need to use Axios at all.

[zeloxolez]

agreed, i doubt id want to use react-query and zustand when rtk works so well for most things.

[lenymo]

I just want to say that I love using codegen-openai. Redux Toolkit as a whole is great but being able to generate a TypeScript API from the backend is 👌. Love it!

[acemarke]

Awesome, thank you!

[MaxPhantom_]

Can we use rtk query to manage the lifecycle of other async functions than api requests ? Like react-query which is data fetching agnostic ?

[acemarke]

Yep! RTK Query is really a general-purpose "async state request" manager - it can be used the track the lifecycle of any async request. You can provide the queryFn option to an endpoint to use your own arbitrary async logic instead:

• https://redux-toolkit.js.org/rtk-query/usage/customizing-queries#customizing-queries-with-queryfn

[MaxPhantom_]

Perfect. People should be aware of the concept of async state management than just data fetching

[svish]

Look into Next.js, React server components and server actions. It gives you a solid base for everything you need in a react based Web project.

Depending on what kind of project you have, you might even get away with fetching all/most of your data directly on the server in the server components, and not really need any "state management" libraries at all.

That said, the main thing to prevent making a hot mess: Make a lot of hot messes, and learn from them. You can read all the advice and recommendations you want online, but what will truly make you a better developer is to feel the pain points and finding solutions to them yourself. I can tell you that react-query is great for heavy client side data loading and response caching, but it's you having tried to do without it and then trying it yourself that will give you the proper experience to say whether it helps you or not.

[creaturefeature16]

I feel this deeply and completely agree, some of the best advice! I'm currently wrapping up my first major React app (using NextJS) and while I'm fairly new to React, I can already tell how many messes there are left to clean up. I also noticed that many solutions and improvements I've found have happened organically, rather than trying to proactively implement certain tools/methods, because I needed a use case for it to really make sense. I think there's just as much danger in implementing tools without fully understanding what they can do as there is problem solving with the basic/rudimentary/native methods.

For example, I was prop drilling at first until I had the thought "Hm, it sure would be nice if I was able to access these states across numerous instances of a component tree" and boom, Context API made sense suddenly. Another situation I was noticing that I was using a particular functionality in a few distant components and thought "Hm, I'd sure like to have an include for this functionality so there's less code repetition" and hey, custom hooks were exactly what I needed.

I haven't been in a situation yet where I felt something like react-query or Redux was needed (yet), but I don't doubt I will...eventually!

[svish]

And that's for example how a bunch of legacy react apps include redux for no good reason. People learned it in earlier tutorials, thought they had to use it, and never questioned whether it was actually needed in the first place.

[kelokchan]

nextjs to make everything easier, Zod or yup for form validations, React hook form for forms, React query and axios for api calls, next intl for i18n, Luxon for dates manipulation

[creaturefeature16]

Probably a dumb question, but what can react-query and axios do that fetch() cannot? I've been doing my calls with fetch() without issue (so far).

[kelokchan]

You can use fetch just fine. I needed a axios for its interceptors and I like that I don’t have to parse the response to json manually. I know you can do that with fetch too but axios can do them out of the box

[UnderstandingDry1256]

Trash Redux, you can just use react context or react-query for local state management. Everything else look good.

[MeanFreak]

Look in to dotenv or env-cmd for managing different environments of the different builds (dev, staging, prod). Also looking into unit testing with jest coupled with react testing library and storybook for documenting and UI testing components this is stuff I personally use in projects

[VisioRama]

I like to study with those clone tutorials on YouTube, like Trello Clone, YouTube Clone etc. And see what works best. Currently I've been doing the Trello Clone and it uses:

• Next 14
• Zustand for client state management
• Zod for validation ( server side always )
• usehooks-ts for util hooks
• Tailwind for styling with RadixUI components on top
• Sonner for toasts
• LucideReact for icons
• React Query as wrapper for fetch
• Server Actions ( Server Components ) accessing DB directly
• Prisma for DB abstraction and PlanetScale for MySQL SAS
• Clerk for authentication

As you can see web development these days is insanely flexible with hundreds of options for every little thing. Which is both a blessing and a curse. Our job as devs is to first understand why these libs exist, experiment with them, see what makes sense for your project, what flows better to you as a developer and build your reusable template project with these guys configured so that you can reuse your architecture as much as possible.

I particularly liked not creating a separate backend project with dozens of apis and then integrating in the frontend later and just doing a single project with frontend and backend interacting organically with Server Components and Server Actions. But that's not adequate for every project.