DEV Community

Cover image for This Week in Learning 5 - 9 June
Live Long & Ponder
Live Long & Ponder

Posted on

This Week in Learning 5 - 9 June

Interested in what I learned this week? Yes? No? Well I'm going to tell you anyway! Some programming concepts, but also some real-world ideas too.😊


When you're working on creating forms that will be displayed by the browser and you want to do your own custom validation (like YUP or Zod) be aware of including the required attribute on your element. When Chrome sees this, it will usually throw an error and say something to the effect of Please Fill Out This Field before hitting your validation messages. It can be a frustrating experience as a user, but there's one easy solution!

Just include a noValidate as an attribute in your form and your own validation should run without Chrome yelling at you first. like this:

<Form onSubmit={handleSubmit} noValidate>
Enter fullscreen mode Exit fullscreen mode

Firefox does it as well, but this fixes it there too! Tell those browsers to shush.

DTOs and MVC 

I've been trying to wrap my head around Model-View-Controller (MVC) patterns in general and the pattern that includes a service layer. A service layer would sit in between a Controller and Model tasked to complete any domain-specific logic that doesn't exactly fit into just a model or controller.

In that model, there will be Data Transfer Objects (DTOs) that encapsulate data to send from one place to another within an application. This can help reduce the number of calls by basically combining multiple calls into one. There's some logic to help assemble/disassemble these, but that's covered much more in-depth in resources like these.

Martin Fowler Post
DTO Explained

I've only just started diving into these concepts, but DTOs while powerful need to be used in correct situations so that their greatest benefit shines, rather than introducing unnecessary complexity. If you read into Fowler's post you'll see a few examples of when implementing a DTO is a good idea, and when it's not.

When to Separate React Components ⚛

I found a problem this week when using react-hook-form where the whole form kept re-rendering on a change rather than just the field I wanted to change. One solution I found was to separate the problem components out into their own place so that the re-rendering would stop. I was left with a pretty basic form, with other logic held in different files. It worked, but it didn't completely sit right with me. If this happens in other forms and I keep separating things out, at what point does it become an anti-pattern? I want the code to be clean, organized, and concise but how can I do that if I keep moving components out of forms?

I think the culprits were useWatch and useFormContext and not fully understanding controller in that library. If you have any ideas or thoughts on this problem let me know! I'm still learning that library so any ideas or thoughts on understanding are welcome.

Final Thoughts 💡

While there were a lot of programming findings, I also wanted to document some thoughts on life.
Be kind and patient to those you interact with, because you don't know everything going on in their lives, and they don't know everything in yours. Work can be stressful, but outside life can be even more strenuous, and everyone processes those 2 things very differently. Sometimes happy events for others can remind people of past pains, and all we can do is have an open heart for our fellow humans.

Keep an open mind to learning in all things, whether it's about programming or the person next to you, you never know what beauty you'll find within!
…Until Next time =)

Top comments (0)