Design comparison
Solution retrospective
1- Before this challenge the built tool that I used was parcel which is a module bundler with zero confgration but for this projcet I used webpack is the toatal opposite of parcel when is comes to configuation. While you could use default configuration which can save you alot of time I wanted to learn the inner working of webpack and configuring it for this project give a good grasp on basics like loader and entry files. I hade some issue making the HMR(Hot module replacement) work of htm file but it will make a good challenge for the next project.
2- Being stratigiec about the way you import partials or functions in different namespaces can save you alot of typing/time. For instance if you use something like a function that converts pixel value to rem values you can import it once in you main entry file instead of importing is in each partial or having to use a namespace.
block{ padding: rem(a value) }
3- Commit history is really valuable asset for debugging purposes and a bunch of other reason therefore creating a logical and descriptive one is important. A bad practice is to only use none-specific commit messages like "added some styles". A much better commit message has the following structure:
1-Subject
2- Body:
1- what have you changed or added?
2- the purpose of change
3- dangers
Bugs
1- When content of a contaienr changes dynamically you have to acount for that when you writing styles for that contaienr. For instance if you set the content of each timer__box to a four or more digit number the content overflow. This problem could be migtigated using relative units like em.
Community feedback
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