Hey friends this is another answer to that lengthy email from Poeter I'm

not sure how to say that but properly sorry but the question is how do youwrite code that can be easily tested and they go at length to explain, youknow, sometimes you write, you know smaller functions and we can test thoseeasier but ultimately like, it doesn't always work that way componentstypically grow and splitting them up makes it feel harder to maintain and Itotally agree with that.

I have a blog post called when to break up a react component.And I

typically preferred don't break it up if you can help it avoid breaking upyour components unnecessarily so yeah, so I prefer having bigger componentsbut then like okay, so how do I test this it's got a bunch of use effectsand whatever else in it and then they also bring up the container or yeahthe like the smart and dumb components sort of thing or whatever we landedon for the macular for that but I actually never liked that pattern either.

I didn't think that it was a useful.Mechanism for splitting components up

or anything it didn't make any sense to me. I mean, I understood like whatthe rules were but the rules were stupid. I thought and never got any valueout of that, so how do we write react components or just code in generallet's easier to test well.

I think that if you're testing from a user's perspective and focusing not

on building like running necessarily testable code, but just code that'sthat's sensible that makes sense like there's you're not breaking things upunnecessarily and you're.Associating things across like that are in thesame vertical I guess like yeah just not breaking things up unnecessarilyand then you test them from the user's perspective, it really doesn't endup mattering how complicated the code within it is necessarily especiallywhen you're we're talking about unit or integration tests where you'remocking HTTP calls that stuff as long as you have MSW to intercept requestsand and mock those out and then occasionally maybe mocking a third.

Party library that's complicated or something from there it's it's just

rendered the thing and interact with the thing the way that the user doesand then assert on its output. I never really think too much about makingmy code testable necessarily and maybe that's just the curse of knowledgeon me just learn to do that naturally and it's something you develop overtime, but it's not really something.

I'm thinking about a whole lot. I guess one thing that I do is I I

typically avoid doing side effects in the root level of a module and Ialways put those in a function and that can help make things a little moretestable but in general, I'm not really.

Thinking about it too much. I hope that's sort of helpful bye.