Time Tracking Dashboard with Tabs pattern

Community feedback

• 

  P

  Kamran Kiani•1,280

  @kaamiikPosted 4 months ago

  Hi

  Congrats for doing this challenge.

  I think on the card the whole card must be clickable. I read this article for this and It was really helpful. Also when you hover on the ellipsis button the card color should not change. Using :has pseudo class really helps here.

  For the tabs I think if they work with left and right arrows It's better. I'm not sure It's right or wrong It's only a suggestion :)

  Marked as helpful

  1

  ---

  

  T

  Gwenaël Magnenat•1,290

  @gmagnenatPosted 4 months ago

  Hi @kaamiik 👋, thank you for your comment !

  Thank you for the link too, it's a good one. I used the pseudo content trick on another challenge, it's great to know. For the card that's actually a part of the design i'm a bit confused with, in your opinion, what would the card link to? I'm sure it's not the same as the ellipsis button, these should open a menu with option for the card.

  For the tabs I implemented both by following the w3 documentation on tabs pattern. https://www.w3.org/WAI/ARIA/apg/patterns/tabs/ In the note it mention something about orientation of the tabs. I used matchedQuery to set the corresponding keys for the navigation. I didn't handle screen size update so you need to refresh your screen to test it on the mobile layout.

  0

  

  P

  Kamran Kiani•1,280

  @kaamiikPosted 4 months ago

  The h3 should be the link but the text should wrap inside an a tag and the whole card must be clickable as you see when you hover over card the bg-color change. Just like the design of the figma file. Ellipsis I think is a button that open a menu.

  Yes you are right when I refresh I can use left and right. Personally I used both of them for desktop and mobile to make it easy :)

  Also I see on your design the .dashboard does not have any top and bottom margin and the div is stuck to the top and bottom of the page. It's better to have a block margin.

  @gmagnenat

  1

  

  T

  Gwenaël Magnenat•1,290

  @gmagnenatPosted 4 months ago

  @kaamiik thanks for your active feedback ! I pushed an update changing that h3 element in an <a> tag and made the whole card clickable.

  I also added a small padding block on the body to add space on top and bottom. You are right it looks a bit cleaner :)

  Thanks !

  1

  

  P

  Kamran Kiani•1,280

  @kaamiikPosted 4 months ago

  Your Welcome @gmagnenat

  0
• 

  Alberto Raúl José•610

  @alberto-rjPosted 4 months ago

  Congrats @gmagnenat!

  Very well written solution, very well written README.md. Doing this has been one of the hardest things for me, do you have a tip/advice for me to get better at it?

  What could be improved:

  According to style-guide.md, you could use fonts with weights 300, 400, 500, instead of 300..900. By doing this, the page load time could be saved even more.

  What inspired me:

  • Code that is easy to read and maintain.
  • Implementation of the tabs pattern.

  As for the approach you took using the fetch API, I also thought it was very well written. In fact, your solution is very good overall, it made me think about refactoring my own solution. Thanks @gmagnenat.

  Marked as helpful

  1

  ---

  

  T

  Gwenaël Magnenat•1,290

  @gmagnenatPosted 4 months ago

  Hi @alberto-rj 👋 Thanks a lot for your positive feedback. I’m actually really happy that you find inspiration in my solution, you make my day 😃. I spent quite some time on this one before posting it. For the readme I usually keep bullet point notes and links while working on the project. I start with the template and remove all the comments. When I’m close the end I develop some of the bullet points in more explanation but always trying to think about something that could be important or useful for another developer reading the document.

  1

  

  Alberto Raúl José•610

  @alberto-rjPosted 4 months ago

  Next time I will also consider these points when writing my README.md file. Thanks for the feedback @gmagnenat, it was useful!

  0
• 

  P

  markus•2,250

  @markuslewinPosted 4 months ago

  Hi!

  Only data.json needs to be in the public folder if you want to fetch the data. It's better to keep the JS out of the public folder, and let Vite optimize the file during build. This also allows for a better DX, since Vite can refresh the page automatically as main.js is being updated.

  You might've used this challenge to practice fetching data, but just in case you didn't know, Vite supports importing JSON from JS, so another way of using the data is to simply import the data as if it was just another JS module:

  // main.js
  import fetchedData from "./data.json";
  

  Marked as helpful

  0

  ---

  

  T

  Gwenaël Magnenat•1,290

  @gmagnenatPosted 4 months ago

  Hi @markuslewin ! Thanks for the feedback I will try this right away :)

  1