This repository has been archived by the owner on Feb 8, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
removed chakra-ui & revamped website #171
base: main
Are you sure you want to change the base?
removed chakra-ui & revamped website #171
Changes from all commits
137fffd
818f66b
6f30b30
67b4d3c
727b4a0
35983d7
9c7038b
acbc1ef
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use Type Aliases instead of Interfaces just for following a uniform standard practice across the project's source code?
I used Type Aliases elsewhere mainly because I don't need them to be extended & composed for say a third-party user. Generally speaking for internal usages (as in not to be imported in to a third-party project), Type Aliases are the way to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
props
parameter can be directly destructured (and is the recommended approach to writing Functional Components right now).Here's an example:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving forward with Functional Components, using
defaultProps
is redundant. You can now directly default values to the props like the example below:This is way MORE readable, has less code to write & follows the uniform standard across the rest of the source code.
For more information on the same, refer to the official documentations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the "newsletter" section of the footer area right? Can you add a TODO comment here for future reference? It's easier to lookup for TODO comments across all the files in the source code & fix the issues later on. My justification for doing so is because we need to setup some mailing list service before this function can hook in to it.
Like add a comment on the lines of:
TODO: Setup a Mailchimp account & see if it works.