Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found
Not Found

All solutions

  • Submitted


    This was another fun challenge to work on!

    I must say that the responsive design in this challenge was a monster to deal with, but nevertheless I am proud of how it turned out.

    One area that I would like to seek advice on is overlay scrolling. When the modal appears, double scrollbars are visible for smaller desktop screens. Not too sure how to get rid of them, ideally I want only one scrollbar to be present. When the modal appears, I want it such that the background stays in place and cannot be scrolled, while the modal can be scrolled if it has too long of a height.

    One solution that I tried was to set overflow: hidden when the modal appears, but doing so will cause the background to "jump" to the top if the modal was made to appear at a scroll position that is not the initial. I didn't want to go with this solution as this makes for a more jarring user experience than the ugly double scrollbars.

    As always, if there are any areas I could have done better or anyone has a different way of doing a certain thing, they are all welcome!

  • Submitted


    This was a really fun project to work on! I did have some troubles with the responsive design though, especially the divider that appears on smaller screens to separate the title and the theme toggle.

    There is one particular area that I would like to seek some advice on. My <main> section is positioned absolutely on top of the .app-top-bg element. Because of this, the parent element (containing both my .app-top-bg and <main> elements) "wraps" around the app-top-bg element only, since it is part of the normal document flow but not the <main> element.

    Coincidentally, this looks fine in light theme because the background color of the app is white in light theme, which is the default for the html body. But when in dark theme or if the background color of the light theme was to be different, the background color of the application will remain the html body default (i.e. white). This is not because the background color isn't applied, but because the background element with the background color applied has height equal to the .app-top-bg element.

    The workaround I found for this was to use document.querySelector to select the parent element using its classname, and get its scrollHeight so as to set the height of the parent element. This works, but I'm not really satisfied with it, since to a certain extent, I would consider it to be hardcoding. As such, I'm wondering if there is a better way to approach this.

    Also, I would like to ask for feedback in the following areas (but not limited to):

    • structure of the react components
    • structure of the CSS files
    • the semantics of the html tags used

    Any comments on how they could have been done differently (and better) or in any other areas are also welcome!

  • Submitted


    I would like to ask for feedback and best practices in the following areas:

    • Project Folder Structure

    Reason for using the project structure that I have is because I want to keep things modular, this allows the component to be plug-and-play and it can be reused in another project if need to, and all that needs to be done is to simply copy the entire folder over. But of course, doing so will mean that there will be a lot of folders containing a small number of files, and this might not be appropriate for a project at scale.

    • Architecture of the Component

    I'm looking for comments on what can be done to structure the component and its child components better. What I've done is I have broken up the component into many smaller components because I feel there are a number of benefits to keeping the file size small (ideally <100 lines implementation-wise):

    1. Reduces the contextual text volume that another person has to process if he/she is a collaborator or is taking over the project and need to make some changes (beneficial to peers)
    2. Easier for code reviews in a collaborative setting (beneficial to managers)

    Any other comments are also welcome! For example, what can be done better for the choice of CSS structure or naming convention (used BEM for this project but I don't know if it's correctly used), just to name a few examples.

  • Submitted


    I completed this challenge months ago and never really thought about submitting it until now. This challenge itself doesn't really have much to go over, so I am looking for any general comments for areas that can be improved upon. For example (but not limited to the following):

    • Were the html tags used semantically appropriate?
    • How can the CSS be structured better?