Tip-calculator-Typescript-SCSS-Animation-Accessibility-Jest
Design comparison
Solution retrospective
I'm most proud of revisiting my project to test it with Jest and applying previous feedback. Finding and fixing a bug that I wouldn't have noticed otherwise was incredibly rewarding. Next time, I’d focus more on writing tests from the start and validating calculations thoroughly, possibly using a TDD approach. I’m also excited to go back to my old projects and test them all—it might drive me a bit insane, but it’s a great way to get really good at testing code and improving overall quality!
What challenges did you encounter, and how did you overcome them?The biggest challenge was configuring Jest to work with TypeScript and Vite, which was quite complex. I tackled it through extensive troubleshooting but plan to try Vitest next for a potentially simpler setup.
What specific areas of your project would you like help with?I’d appreciate feedback on the following areas:
Testing: I’m unsure if my test cases cover all essential aspects and may have missed some important tests. Due to the project's small size and lack of modular components, these unit tests also function as end-to-end tests. I plan to learn Cypress for larger projects.
SCSS: Feedback on styling, organization, maintainability, and best practices would be great.
TypeScript: Any tips on improving code quality, type usage, or overall structure would be helpful.
Any additional feedback is also welcome!
Community feedback
- @sirajsharmaPosted 3 months ago
I noticed that in the
_calc.scss
partial file, you used descendant combinators with quite a bit of nesting. For example:.form { .input-container { .input-icon {} } }
This compiles to CSS as:
.form .input-container .input-icon {}
Using descendant selectors like
.form .input-container .input-icon
specifies styles based on a very specific structure. If you need to use.input-icon
elsewhere, you'll have to recreate the same rules, leading to redundant code.In large projects, this approach can cause issues due to the high specificity of descendant selectors, which can override other rules. This often leads to the overuse of
!important
to fix conflicts.Consider using BEM (Block Element Modifier) to structure your rules more effectively. BEM works well with SCSS and can help manage specificity and modularity.
Another point is that you didn't break down the components, which affects adherence to the Single Responsibility Principle (SRP). Breaking down components could have facilitated writing more modular SCSS.
While you employed advanced concepts in React and TypeScript, focusing on these smaller details could enhance the overall quality of the code. Despite these issues, I really liked the end result and am excited to tackle this challenge myself now.
Marked as helpful1@TedJenklerPosted 3 months agoThank you for your time, @sirajsharma. I agree that I sometimes nest a lot and have had issues with that from time to time. I’ll check out all these topics; they seem interesting.
1 - @MikDra1Posted 3 months ago
Hi,
I see you made this challenge second time. That's great that you want to improve 😃. One thing that I would change is the font-family. I see you have the default one but it should be the font specified in style-guide.md
Hope you found this comment helpful 💗💗💗
Good job and keep going 😁😊😉
Marked as helpful1
Please log in to post a comment
Log in with GitHubJoin our Discord community
Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!
Join our Discord