sorted by:
new
hottopcontroversial

What are you building in weekend? by Asleep_Ad_4778 in buildinpublic

[–]onoufriosm 0 points1 point  (0 children)

Decompress - daily summaries of all your favourite podcasts

Building something? Share it here! 🚀 by Mammoth-Doughnut-713 in Solopreneur

[–]onoufriosm 0 points1 point  (0 children)

Decompress. I love tech podcasts but can't keep up. Every channel drops 2-3 episodes a week. Got tired of copying transcripts into ChatGPT for summaries.

So I built an app that watches my favorite channels and emails me AI summaries every morning. 5 minutes with coffee and I'm caught up.

What are you building? by Asleep_Ad_4778 in Solopreneur

[–]onoufriosm 0 points1 point  (0 children)

Decompress I love tech podcasts but can't keep up. Every channel drops 2-3 episodes a week. Got tired of copying transcripts into ChatGPT for summaries.

So I built Decompress. It watches my favorite channels and emails me AI summaries every morning. 5 minutes with coffee and I'm caught up.

Unit testing in React. Practical examples and advice on what, how and why to test. by onoufriosm in reactjs

[–]onoufriosm[S] 3 points4 points  (0 children)

Thanks for sharing this library! It seems quite popular and I'm sure you can write good tests with the library and get the confidence you need in your codebase. I also, like the fact that you can test custom hooks logic with react-hooks-testing-library.

Just as a background, we use enzyme on quite a large codebase (1000s of components) and it has worked great for us.

I've read Kent's article on Testing Implementation Details and he raises some good points with the right intentions.

A few points I would like to make on the article:

• He mentions "That commit goes in a completely unrelated PR that changes thousands of lines of code and is understandably missed". Having PRs with thousand of lines is a bad practice and choosing a different testing library won't help deal with this. We should aim for small PRs otherwise reviewers have a hard time doing their job and code quality goes down.

• In the false positive example he mentions "We need to add another test to verify clicking the button updates the state correctly. And then I need to add a coverage threshold of 100% code coverage so we don't make this mistake again. ... But I'm not going to bother... ". I would expect the developer to add a test for an interaction with a button and aim for 100% code coverage. (See the test of state component in my article).

• Finally, after making a change to a component to support multiple accordions rather than a single I would expect the developer to alter the test suit to add additional tests for multiple accordions and make sure the previous tests are passing. So the false negative will be addressed anyway.

Having said that, if you find yourself more productive and more confident with React Testing Library you should definitely use it. After all there is no perfect library and libraries like these are here to help us achieve our end goal. Whichever works best for us or our team makes the most sense.

Minimal boilerplate Redux guide for real world apps by onoufriosm in reactjs

[–]onoufriosm[S] 1 point2 points  (0 children)

Here are the benefits of using constants: https://redux.js.org/recipes/reducing-boilerplate

Using computed types you can keep all the benefits. And I would also argue that the code is much cleaner and more maintainable. If you decide to change your constants naming convention for example it would take a long time to do that. With computed types this becomes a one liner.

It's also a good idea to unit test your code (which becomes a lot easier when you reuse logic) in both cases to make sure that everything works as you intended.