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

ReactJs, Sass, Flex, Grid

Nikolas Matias•65
@NikolasMatias
A solution to the Tip calculator app challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


Hi everyone! I'm not this good at Front-end but I tryed my best to make it work so I hope u all like it.

Soo I would like suggestions about what I could do to improve, any tip?

Btw I used the "/ person" part in css and the answer of the errors in css too using before and after, is it a good way to do it? I was trying to improve my skills doing it.

There's a difference between the "height" value of buttons and inputs? I tryed to do the "Custom" button with the same "height" of the buttons but it didn't work.

Btw I tryed to align the text inside the button too but it didn't work very well, any advice?

Thanks everyone!

Code
Select a file

Please log in to post a comment

Log in with GitHub

Community feedback

  • Rafal•1,395
    @grizhlieCodes
    Posted almost 4 years ago

    Hey Nikolas,

    Great questions overall. I'll try tackling them and anything else I notice.

    1. Height = 👿 in most cases, allow me to explain... I think where responsiveness is concerned it is best to let the content decide its' own height, the only things I usually manipulate is width, but sometimes not even that.

    Let's take this button for example. I used no height, no width but it looks perfectly fine, I think you'll agree? We can change the font-size, line-height, write different/more/less content and the button will still function perfectly well. Nothing about it is fixed except the content (text related styling). I used font-size and padding to create the height. The browser can do all the calculations for me, saves us time and leaves components/elements more responsive.

    Approach every single HTML element this way except major things like body. Everything else can just use content + padding to create the majority of its' height and width.

    So to anwser your question, height does not differ for anything. Inputs/buttons work more or less the same. But it is best to leave both without any height and instead opt for the above suggestion, I think you will find that this is a more responsive and natural way of thinking for just about anything.

    1. On the topic of responsiveness - avoid setting widths for most things, unless the design specifically requires it.

    2. You used a more traditional approach of using % units in your css grid. Whilst this is correct, you are again doing the browsers work for it, there is a simpler solution thankfully 😁: fr units.

    Instead of using grid-template-columns: repeat(2, 45%) in order to 'calculate' for the grid-gap, we can just use grid-template-columns: repeat(2, 1fr). The browser will calculate used space (grid-gap) and it will then spread the remaining space into 2 columns, each taking 1 fraction (50%) of this remaining space.

    Moral of the story - fr units are the more intuitive and calculation-free way of 'doing grid'.

    1. grid-template-rows: minmax(30px,auto) repeat(3,30px) seemed a bit complicated. Assuming you let the content dictate sizing we can just use min-content here, and in some cases max-content.

    Instead of using grid-template-rows we can sometimes opt in for grid-auto-rows and let the browser do even more work for us. Assuming we styled our elements to be the correct size, assuming we have preset a gap for the rows, and perhaps added a margin-bottom to the very top (Heading) element, select tip % in this case, we can just try grid-auto-rows: min-content;. This is actually more or less what grid does by default but at least you know this is an option now, a very useful option mind you.

    1. If you do the above suggestions you will also find that you can remove text-align: center; from the button. It also means that instead of padding-bottom you should just use padding so we have spacing everywhere. Obviously I'm recommending for you to remove height. And justify-content: center; does nothing outside of flex/grid so remove that as it is not able to do anything there. Your button should be sized more correctly. Feel free to sometimes add a min-width to things though. And max-width to elements like body or main containers that require it.

    To summarise: try not using fixed units where heights and widths are concerned. Use paddings/font-sizes/line-heights and the content itself. Sprinkle in some min/max-widths for some control where needed.

    Use fraction units for css grid, dabble in min/max-content and study what these do. A good study would be minmax(min-content, 1fr), this is a completely responsive solution to some problems you'll find along the way.

    If you have any questions about the above or any other questions then feel free to ask, I'll try responding if I can 😀

    Cheers,

    Rafal

    Marked as helpful

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 all CSS, SCSS and Less files in your repository.

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.

How does the JavaScript validation report work?

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

The report picks out common JavaScript issues such as not using semicolons and using var instead of let or const, among others.

The report will audit all JS and JSX files in your repository. We currently do not support Typescript or other frontend frameworks.

Oops! 😬

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

Log in with GitHub