Skip to content
OverviewSolutions
11
Comments
11
P

kephalosk

@kephalosk260 points

I’m a mysterious individual who has yet to fill out my bio. One thing’s for certain: I love writing front-end code!

Latest solutions

View more solutions

Latest comments

  • P
    Valeria Montoya•400
    @ValeriaMontoyaSubmitted about 1 month ago
    What are you most proud of, and what would you do differently next time?

    It was an exciting opportunity to apply my knowledge of JavaScript and asynchronism. Additionally, it marked my first experience working with JSON files, which added an extra layer of learning and growth.

    What challenges did you encounter, and how did you overcome them?

    Writing readable asynchronous JavaScript was challenging, so I ended up using the async/await syntax.

    What specific areas of your project would you like help with?

    I'd love to hear your feedback on JavaScript 🤓

    Responsive time tracking dashboard

    #sass/scss
    1
    P
    kephalosk•260
    @kephaloskPosted about 1 month ago

    Nice solution :) I had a look at your js-script. I noticed you used defer in your index.html and document.addEventListener('DOMContentLoaded',...) in your script.That is obsolete/redundant. e.g. at top of the script you load the buttons. that is only possible because the DOM is already loaded at this point. If you want that defaultButton-click happens at last you could pack it into a function and wait for the others before. You could also improve the structure of your js-code by leading the reader through the code semantic and chronological. You could start with some kind of Entrypoint at the top and giving clear steps from there for a cleaner structure, e.g. here is the exact same code you wrote, just in a chronological order and semantically structured. :

    await initializeApp();

async function initializeApp() {
    await addEventListenersToButtons();
    initializeStatsWithWeeklyValues();
}

async function addEventListenersToButtons() {
    const buttons = document.querySelectorAll('.profile__button');

    buttons.forEach((button) => {
        button.addEventListener('click', async (event) => {
            await handleButtonClick(buttons, event);
        });
    });
}

async function handleButtonClick(buttons, event) {
    const clickedButton = event.target;
    const period = clickedButton.id;

    buttons.forEach((button) =>
        button === clickedButton
            ? button.classList.add('profile__button--active')
            : button.classList.remove('profile__button--active')
    );

    await updateStatsByPeriod(period);
}

async function updateStatsByPeriod(period) {
    switch (period) {
        case 'daily':
            await updateStats(period, 'Yesterday');
            break;
        case 'weekly':
            await updateStats(period, 'Last Week');
            break;
        case 'monthly':
            await updateStats(period, 'Last Month');
            break;
    }
}

async function updateStats(period, periodLabel) {
    const currentTimeValues = document.querySelectorAll('.stats__current');
    const customPeriod = document.querySelectorAll('.stats__period');
    const previousTimeValues = document.querySelectorAll('.stats__value');
    const data = await fetchData();

    data.forEach((element, i) => {
        currentTimeValues[i].textContent = `${element.timeframes[period].current}`;
        customPeriod[i].textContent = periodLabel;
        previousTimeValues[i].textContent = `${element.timeframes[period].previous}`;
    });
}

async function fetchData() {
    try {
        const response = await fetch('/data.json');
        return response.json();
    } catch (error) {
        console.error(`Could not get data: ${error}`);
    }
}

function initializeStatsWithWeeklyValues() {
    const defaultButton = document.getElementById('weekly');

    if (defaultButton) {
        defaultButton.click();
    }
}

    As a rule of thumb you can ask, if a code-block is greater than 20 lines if it would be better to split it down in functions with meaningful names. if you start to code like this you don't even need a documentation because then your code is the documentation. Keep up the good work :)

    Marked as helpful
    0
  • daniel•205
    @danielashjariSubmitted about 1 month ago
    What are you most proud of, and what would you do differently next time?

    the things I'm most proud of:

    • readable clean code
    • the time took me to do this project
    • a good validation code (with the help of kiara523)

    things I'd do differently next time:

    • use a framework for validation
    • use a different approach to toggle elements
    What specific areas of your project would you like help with?

    i've put the element in the center but its not like that in the screenshots, how should i fix it

    • how to toggle elements using
    element.style.display='none';
element.style.display='flex';
    • how to choose an img that wouldn't have problem when published in github pages

    Newsletter sign up with success message

    #sass/scss
    1
    P
    kephalosk•260
    @kephaloskPosted about 1 month ago

    Hi, solid solution :) I see you are using 2 css classes to toggle visibility. That is a bit redundant and leaves room for bugs, because you have 4 possible states instead of 2 (hidden/flex/noHiddenNoFlex/hidden+flex)

    messageHolder.classList.toggle('hidden');
messageHolder.classList.toggle('flex');

    A better approach is to set your component to display: none; and add 1 toggle-class to set it to flex, e.g.:

    messageHolder {
  display: none;

  &.active {
    display: flex;
  }
}

    now just can just do only 1 toggle and your component is more stable because it now has only 2 states (display-none/display-flex)

    messageHolder.classList.toggle('active');

    And I saw in-code-styling in your code:

    email.style.backgroundColor = "rgba(255, 98, 87, 0.17)";

    It's better to avoid in-code-styling and do it the same way like you did with the toggle-class. In-code-styling can get in conflicts with css-files. So it's better to control the styling only via css-files/css-classes. Keep up the good work :)

    Marked as helpful
    1
  • LincolnBollschweiler•350
    @LincolnBollschweilerSubmitted 2 months ago
    What are you most proud of, and what would you do differently next time?

    Figuring out Github Pages for a vite.js build, deploy workflow, and yaml was the biggest challenge.

    Also happy that I saved off a copy of my base setup for use in upcoming projects.

    What challenges did you encounter, and how did you overcome them?

    The biggest hurdle was figuring out that Vite's documentation, suggesting that a default vite.config.js would work, was incorrect. The packaged css and js need to be accessed from the dist root with base: "./", NOT with base: "/" (which comes free, no config).

    I tried to change the raw html <head> tag to point to "./" for the assets files, but it just resets on refresh.

    In the end, I made a best guess in updating vite.config.js and it worked.

    Responsive card w/ javaScript

    #jquery#vite#sass/scss
    1
    P
    kephalosk•260
    @kephaloskPosted about 1 month ago

    nice solution :) I noticed your deep nested s/css structure:

    ...
            &::after {
              content: "";
              position: absolute;
              top: 100%;
              left: 50%;
              transform: translateX(-50%);
              border: 0.5rem solid transparent;
              border-top-color: var(--darkGrayishBlue);
            }
          }
        }
      }
    }
  }
}

    It's better to flatten the hierarchy. That looks cleaner and improves readability.

    0
  • P
    kephalosk•260
    @kephaloskPosted about 1 month ago

    nice solution :) I went through your s/css code and noticed some deep-nested elements:

    .hero {
    &__img {
      margin-block-end: 4.5rem;
    }
    &__app {
      margin-inline: 7.2406em;
      &-title {
        font-size: base.$fs-48;
      }
      &-button {
        flex-direction: row;
        gap: 17px;
      }
    }
  }

    That is problematic because other devs could think that e.g. hero__app-button would inherit the properties from his parent element hero__app, but that is not true. You have there 2 different css classes that are not related too each other. So, it is better to separate them. That gives your css code a cleaner look and improves readability, e.g.:

    .hero {
...
}

hero__app {
  margin-inline: 7.2406em;
}

hero__app-button {
  flex-direction: row;
  gap: 17px;
}

hero__app-title {
  font-size: base.$fs-48;
}

hero__img {
  margin-block-end: 4.5rem;
}
    0
  • P
    kephalosk•260
    @kephaloskPosted about 2 months ago

    Nice solution :) I had a look at your card.component.scss and noticed the deep nested structures:

    .container {
...
  header {
...

    .name-container {
      p {
        margin: 0;
      }
...
    }
  }
...
}

    In S/CSS it's best practice to avoid deep nesting of elements. A flatten hierarchy improves the readability of your code, e.g.:

    .container {
  padding: 1.15rem 2.3rem;
  border-radius: 10px;
  background-repeat: no-repeat;
  background-position: right 2rem top 0;
  background-size: 100px;

  @media (min-width: 1200px) {
    background-position: right 6rem top 0;
  }
}

.name-container {
...
}

header {
  display: flex;
  align-items: center;
  gap: 2rem;
}

p {
  margin: 0;
}
    Marked as helpful
    0
  • P
    kephalosk•260
    @kephaloskPosted about 2 months ago

    solid solution :) I had a look at your s/css files and saw this:

    main {
    header {
        article {
            width: 100%;
            p {
                width: 60%;
            }
        }
    }
}

    That's an over-nested structure. Avoid deep nesting in s/css. It makes the code harder to read and maintain. Better approach is to flatten the structure. This improves readability:

    article {
    width: 100%;
}

article p {
    width: 60%;
}
    0
View more comments