footer component #130
footer component #130
Conversation
Added |
src/views/Home/Home.scss
Outdated
| a { | ||
| color: inherit; | ||
| } |
There was a problem hiding this comment.
Could we use class names instead of generic attributes? I understand why we have this here, but I don't see the a tag anywhere within Home index view. Let's give the a tags a classname within the Footer component and style the attributes there.
There was a problem hiding this comment.
That's understandable - no problem!
| @@ -0,0 +1,52 @@ | |||
| import React from "react"; | |||
There was a problem hiding this comment.
Because we upgraded to a new version of typescript in #71, we no longer have to import react if we don't use it. Instead, we can import it using the following since this is the convention that it is moving towards using this newer version of react:
import * as React from "react";
There was a problem hiding this comment.
Okay, cool ~ no problem! In that case, we might want to change this notation for all other files too!
There was a problem hiding this comment.
Yeah -- I believe I ran a command that changed all the existing import statements. This only appears once or twice in the codebase. I did a cmd + F on the existing codebase and it looks like I added the wrong import statement after the PR was merged in. I think we should address those in a separate PR. Thoughts?
There was a problem hiding this comment.
Yep! I was lowkey planning a separate PR to just clean up the codebase a little bit, so that sounds like a good idea!
| </div> | ||
| <div className="Footer__text--middle"> | ||
| CruzHacks was formerly known as HackUCSC, and launched in April 2014. | ||
| The founders were |
There was a problem hiding this comment.
SUPER NIT: I'm honestly not that bit a fan of having directly in the codebase as it creates a bit of messy code. We can instead style the a tag accordingly . I'd prefer if we styled it using SCSS instead of hardcoding it into the text like that.
There was a problem hiding this comment.
I agree that these entities make code look a little unclean, but I'm not quite sure what about the resolution that you mentioned. The entities are here, because our linter requires that content within a tags be placed on a new line. Although I personally prefer inline a tags, this causes sentences to be partitioned weirdly and requires used in place of any trailing spaces that are pre-maturely truncated.
Let me know if this makes sense and how to proceed - also note that this section will be removed later when this sentence is integrated into our Teams or Sponsors page.
There was a problem hiding this comment.
Ahh yes! I see what the issue is. Since the a tag has 3 props and contents within it, in order to maintain the character count for that line to 120, it makes the a go to a separate line. Adding a space at the end of the line before the a tag would cause the linter to cry since we don't want trailing spaces. In order to remove these entities, we can style it in the css by adding a margin-left: .5rem to the a tags.
There was a problem hiding this comment.
Ohh, that sounds like a clever fix! I'll have that done by tonight!
tim-nguyen-cs
force-pushed
the
feature/footer
branch
from
89f3695
to
41f3066
Compare
|
I'll touch this up again when other parts of our webpage get flushed out, but let's get this in! |
* first iteration of footer * revised component styling
* first iteration of footer * revised component styling
Problem
As a prospective hacker,
I would like to view additional footer resources
To resolve more inquiries and questions I have about CruzHacks.
Link to Asana Ticket
Solution
To implement the Footer section of the homepage, flexbox-based positioning and margin alignments were used to replicate the provided Figma design with responsiveness. Although preliminary social media links and other graphics have not been included yet, this first draft outlines boilerplate code regarding how the footer is to be implemented.
Change summary:
Steps to Verify:
git checkout feature/footeryarn start