Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted over 4 years ago

Clock app

Emmilie Estabillo•5,580
@emestabillo
A solution to the Clock app challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


Hey everyone! Here’s my post-op for this app:

Design: For this project, I deviated from the design a little bit and focused on getting it DONE instead of 1:1. Got pretty close though compared to the screenshot :-) The Figma file was a huge time-saver.

  • There was a tenacious ios bug where showing the details shelf will also shift the background image up. In the end, I had to give the background a dedicated div and not nest any other div in it. Painful. I did learn how to hook up my phone directly on the computer and edit the CSS in mobile Safari right then and there to troubleshoot.

  • I used classes to change the bg image from day to night and vice-versa. Putting a default image causes a flash of the default image on load before CSS and JS is applied, and I didn’t want that. I feel like there’s a better way than using classes though. Any suggestions?

JS: Oi. Where do I begin

  • I prefer the 12-hour format, so I naturally needed more JS for am/pm and to convert the hour

  • The quotes API stopped working in the middle of the project, so I had to find an alternative. Main criteria: served over https. I couldn’t find the documentation for the one that I picked, so not sure it was a wise choice. Also as a result, I had to write a random index generator for the quotes array. Plus, the quotes are not specific to programming.

  • Tons of CORS error with the time API. In fact, it’s still happening at time of submission. User may need to hit refresh to have a chance at getting the data. I tried adding the cors-anywhere link when making the call but it didn’t solve the issue. Would appreciate any feedback on this.

  • It was suggested to use an API to set the time, but I opted to use the more reliable Date object for hours and minutes. Telling time is at the heart of the app, and if anything else, it will at least do that and not rely on the API which may or may not work.

  • I initially used Promise.all for making the requests. While it worked fine, it takes a good while for all promises to resolve especially if one (or more) is holding it up. In the end, I refactored to separate calls. I was making a duplicate call for the random quote event listener anyway if I remain on the Promise.all route. Is separating the requests the right way to do it?

Other questions I asked myself: innerHTML or textContent? How to handle the headings in the design - the h2 will be larger than h1? How to make html more accessible?

TODOs: Fix readme, refactor based on comments, maybe refactor layout scss since it’s a bit long, and write about all of this!

Thank you for reading this far! Any suggestions/comments/resources on my code and life decisions lol are welcome below :-)

Code
Loading...

Please log in to post a comment

Log in with GitHub

Community feedback

No feedback yet. Be the first to give feedback on Emmilie Estabillo's solution.

Join 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
Frontend Mentor logo

Stay up to datewith new challenges, featured solutions, selected articles, and our latest news

Frontend Mentor

  • Unlock Pro
  • Contact us
  • FAQs
  • Become a partner

Explore

  • Learning paths
  • Challenges
  • Solutions
  • Articles

Community

  • Discord
  • Guidelines

For companies

  • Hire developers
  • Train developers
© Frontend Mentor 2019 - 2025
  • Terms
  • Cookie Policy
  • Privacy Policy
  • License

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

How does the accessibility report work?

When a solution is submitted, we use axe-core to run an automated audit of your code.

This picks out common accessibility issues like not using semantic HTML and not having proper heading hierarchies, among others.

This automated audit is fairly surface level, so we encourage to you review the project and code in more detail with accessibility best practices in mind.

How does the CSS report work?

When a solution is submitted, we use stylelint to run an automated check on the CSS code.

We've added some of our own linting rules based on recommended best practices. These rules are prefixed with frontend-mentor/ which you'll see at the top of each issue in the report.

The report will audit 1st-party linked stylesheets, and styles within <style> tags.

How does the HTML validation report work?

When a solution is submitted, we use html-validate to run an automated check on the HTML code.

The report picks out common HTML issues such as not using headings within section elements and incorrect nesting of elements, among others.

Note that the report can pick up “invalid” attributes, which some frameworks automatically add to the HTML. These attributes are crucial for how the frameworks function, although they’re technically not valid HTML. As such, some projects can show up with many HTML validation errors, which are benign and are a necessary part of the framework.